"Table of Contents
1.	GENERAL	1
1.1.	Purpose	1
1.2.	Scope	1
1.3.	Responsibilities	1
1.4.	Team Member Responsibilities	1
1.5.	Applicable And Reference Documents	1
1.5.1.	Applicable Documents	1
1.5.2.	Reference Documents	2
1.6.	Acronyms, Abbreviations and Symbols	2
2.	HARDWARE DESIGN LIFECYCLE	6
2.1.	Hardware Design Standard	6
2.2.	Hardware Archive Standard	6
2.3.	Hardware Validation and Verification Standard	6
2.4.	Hardware Requirement Standard	7
2.5.	Validation and Verification Process	7
2.5.1.	Objectives	7
2.5.2.	Validation Process	7
2.5.3.	Validation Process Objectives	7
2.5.4.	Validation Process Activities	7
2.5.5.	Verification Process	8
2.5.6.	Validation and Verification Methods	8
2.6.	Configuration Management Process	8
2.7.	Process Assurance	8
2.8.	Certification Liaison Process	9
2.8.1.	Communication Channels	9
2.8.2.	Documentation Exchange	9
2.8.3.	Review Meetings	9
2.8.4.	Issue Resolution	9
2.9.	Means of Compliance and Planning	9
2.10.	Compliance Substantiation	9
2.10.1.	Certification Authority Reviews	10
2.10.2.	Document Submission	10
2.10.3.	Additional Document Submission	10
2.11.	V-Model Development Approach	10
2.12.	Relationship Between Processes and Activities	11
2.13.	Means of Providing Feedback	12
2.13.1.	Regular Meetings and Communication Channels	13
2.13.2.	Common Data and Document Sharing Platforms	13
2.13.3.	Change Management and Version Control Systems	13
2.13.4.	Error Tracking and Query Systems	13
2.13.5.	Risk Management and Analysis Tools	13
2.14.	Planning Process	13
2.14.1.	Planning Process Objectives	13
2.14.2.	Planning Process Inputs	14
2.14.3.	Planning Process Outputs	14
2.14.4.	Planning Process Activities	14
2.14.5.	Planning Process Tools Usage	15
2.14.6.	Planning Process Transition Criteria	15
2.15.	Development Flow Diagrams	15
2.15.1.	Analog Hardware Development Flow	15
2.15.2.	Complex Hardware Development Flow	15
2.16.	Requirements Capture Process	15
2.16.1.	Requirements Capture Process Objectives	16
2.16.2.	Requirements Capture Process Inputs	16
2.16.3.	Requirements Capture Process Outputs	17
2.16.4.	Requirements Capture Process Activities	17
2.16.5.	Requirements Capture Process Tool Usage	17
2.16.6.	Requirements Capture Process Transition Criteria	17
2.17.	Conceptual Design Process	18
2.17.1.	Conceptual Design Process Objectives	18
2.17.2.	Conceptual Design Process Inputs	18
2.17.3.	Conceptual Design Process Outputs	18
2.17.4.	Conceptual Design Process Activities	19
2.17.5.	Conceptual Design Process Tools Usage	19
2.17.6.	Conceptual Design Process Transition Criteria	19
2.18.	Detailed Design Process	19
2.18.1.	Detailed Design Process Objectives	20
2.18.2.	Detailed Design Process Inputs	20
2.18.3.	Detailed Design Process Outputs	20
2.18.4.	Detailed Design Process Activities	21
2.18.5.	Detailed Design Process Tools Usage	21
2.18.6.	Detailed Design Process Transition Criteria	21
2.19.	Implementation Process	22
2.19.1.	Implementation Process Objectives	22
2.19.2.	Implementation Process Inputs / Outputs	22
2.19.3.	Implementation Design Process Activities	23
2.19.4.	Implementation Process Tools Usage	23
2.19.5.	Implementation Process Transition Criteria	23
2.20.	Production Transition Process	24
2.20.1.	Production Transition Process Objectives	24
2.20.2.	Production Transition Process Inputs	24
2.20.3.	Production Transition Process Outputs	24
2.20.4.	Production Transition Process Activities	24
2.20.5.	Production Transition Process Tools Usage	25
2.20.6.	Production Transition Process Transition Criteria	25
3.	HARDWARE PRODUCT DESCRIPTION	25
3.1.	28 VDC Battery	25
3.1.1.	Hardware Specifications To Be Achieved	25
3.1.2.	Alternative Uses of 28 VDC Battery	26
3.1.3.	Planned Service Life for 28V VDC Battery	26
3.1.4.	Upgrade Considerations for 28V VDC Battery	26
4.	HARDWARE DESIGN METHODS	26
4.1.	Design Policies And Standards	26
4.2.	Requirements Capture and Specification Methods	26
4.3.	Conceptual Design	27
4.4.	Detailed Design	27
4.5.	Synthesis Techniques	28
4.6.	Implementation	28
4.6.1.	Architectural Mitigation Management for DAL A and DAL B Functions	29
4.7.	Production Transition	29
5.	HARDWARE DESIGN ENVIRONMENT	29
5.1.	Hardware Development and Verification Tools	29
5.2.	Programming Languages	30
6.	HARDWARE ITEM DATA	30
6.1.	Hardware Design Data	30
6.2.	Design Documents and Files To Be Produced	30
6.2.1.	Block Diagram of Design Architecture	30
6.2.2.	Schematic Document	30
6.2.3.	PCB File	30
6.2.4.	Gerber File	30
6.2.5.	Pick & Place File	30
6.2.6.	Draftsman Document	31
7.	ADDITIONAL CONSIDERATIONS	31
7.1.	Use of Previously Developed Hardware	31
7.2.	Interaction Among Processes	31
7.3.	Planned Process Technology Options	32
7.3.1.	Use of Commercial-Off-The-Shelf (COTS) Components and Microprocessors	32
7.4.	Assembly and Use Options	32
7.5.	Product Packaging	32
7.6.	Hardware Mounting Options	32
7.7.	Safety Considerations	33
7.8.	Design Assurance Considerations	33
7.9.	Deviations and Modifications to Plans	33
 
 List of Tables 
Table 1 Applicable Documents	1
Table 2 Reference Documents	2
Table 3 Definitions	2
Table 4 Abbreviations	5
Table 5 Planning Process Activities	15


List of Figures
Figure 1 V Model Development Approach	10
Figure 2 Relationship between process and activities	12
Figure 3 Implementation Process Input / Output	22
Figure 4 Hardware Design Process Flow Graph	28


1.	GENERAL
1.1.	Purpose
The purpose of this document is establishing the hardware development approach, methodologies, tools and procedures to be used during the design, implementation, verification, validation and production transition of the battery hardware for Battery System under the Electrical Power System of Heavy Class Attack Helicopter Project. 
1.2.	Scope
This plan defines the approach for the hardware design plan for 28VDC Battery System for the Heavy Class Attack Helicopter Project.
1.3.	Responsibilities
Responsibilities are defined in PL-DO-001-0003 Design Organisation Interface Document.
1.4.	Team Member Responsibilities
Team Members for the project and their responsibilities are described in “PL-DO-001-0003 Design Organisation Interface Document”.
1.5.	Applicable And Reference Documents
1.5.1.	Applicable Documents
Table 1 Applicable Documents
#	Document No	Title
1	BL-SD-001-0002	28VDC Battery System Description Document
2	PL-PHA-001-0004	Plan for Hardware Aspects of Certification 28 VDC Battery
3	PL-HVVP-001-0002	Hardware Validation and Verification Plan
4	PL-DO-001-0003	Design Organisation Interface Document
5	PL-PM-001-011	Project Management Plan
6	PL-HCM-001-0002	Hardware Configuration Management Plan
7	PR-AV-001	Design Procedure (Aviation)
8	PR-AV-003	Safety, Reliability, Maintainability, Testability Management Procedure
9	PR-AV-007	Hardware Design Standards
10	PR-AV-008	Hardware Requirement Standard
11	RP-SSA-001-0001	Preliminary System Safety Assessment
12	PL-HPA-001-0002	Hardware Process Assurance Plan
13	PR-AV-009	Hardware Validation and Verification Standard
14	PR-AV-010	Hardware Archive Standard

1.5.2.	Reference Documents
Table 2 Reference Documents
#	Document No	Title
1	RTCA/DO-254	Design Assurance Guidance for Airborne Electronic Hardware
2	MIL-HDBK-516C	Airworthiness Certification Criteria 

1.6.	Acronyms, Abbreviations and Symbols
Definitions are shown in following table.

The following acronyms and abbreviations may have been used in this document.
Table 4 Abbreviations
Abbreviation	Explanation
AE	ASPİLSAN Energy
CDR	Critical Design Review
CM	Configuration Management
COTS	Commercial Off-The-Shelf
EPS	Electrical Power System
FPGA	Field Programmable Gate Array
HCMP	Hardware Configuration Management Plan
HDP	Hardware Design Plan
HPAP	Hardware Process Assurance Plan
HVVP	Hardware Validation Verification Plan
LRU	Line-Replaceable Unit
QDMS	Quality Document Management System
PCB	Printed Circuit Board
PCBA	Printed Circuit Board Assembly
PDR	Preliminary Design Review
PHAC	Plan for Hardware Aspect of Certification
RTL	Register Transfer Level
RVTM	Requirements Verification Traceability Matrix
SEH	Simple Electronic Hardware

2.	HARDWARE DESIGN LIFECYCLE

2.1.	 Hardware Design Standard
Hardware design standards will be used during the conceptual design process and detailed design process to define the rules, procedures, methods, guidance and criteria for developing and specifying the hardware design. Details given in the PR-AV-007 Hardware Design Standard document. 
2.2.	Hardware Archive Standard
Hardware archive standards will be used to define the procedures, methods and criteria used to retain and archive product data and develop and maintain program and project archives. Details given in the PR-AV-010 Hardware Archive document.
2.3.	 Hardware Validation and Verification Standard
Hardware validation and verification standards will be used during the validation and verification processes to define the rules, procedures, methods, guidance and criteria for validating and verifying the hardware design and implementation. Details given in the PR-AV-009 Hardware Validation and Verification Standard document.
2.4.	Hardware Requirement Standard
Hardware Requirements standards will be used during the requirements capture process to define the rules, procedures, methods, guidance and criteria for developing the requirements. Details given in the PR-AV-008 Hardware Requirement Standards document.
2.5.	Validation and Verification Process
2.5.1.	Objectives
The validation process provides assurance that the hardware item derived requirements are correct and complete with respect to system requirements allocated to the hardware item. PL-HVVP-001-0002 The Hardware Validation and Verification Plan (HVVP) outlines the verification activities necessary to validate that the 28VDC Battery hardware satisfies functional, safety, and performance requirements. It ensures compliance with the designated hardware plans and standards throughout the development process.
2.5.2.	Validation Process
The validation process is intended to ensure that the derived requirements are correct and complete with respect to the system requirements allocated to the hardware item through the use of a combination of objective and subjective processes.
2.5.3.	Validation Process Objectives
The objectives of the validation process for derived hardware requirements are:
•	 Derived hardware requirements against which the hardware item is to be verified are correct and complete.
•	Derived requirements are evaluated for impact on safety.
•	Omissions and errors are fed back to the appropriate processes for resolution.
2.5.4.	Validation Process Activities
Validation Process Activities are explained in the PL-HVVP-001-0002 The Hardware Validation and Verification Plan document.
2.5.5.	Verification Process
The verification process provides assurance that the hardware item implementation meets the requirements. Verification consists of reviews, analyses and tests applied as defined in the PL-HVVP-001-0002 The Hardware Validation and Verification Plan (HVVP) plan document.
2.5.5.1.	Verification Process Objectives
The objectives of the verification process are:
•	Evidence is provided that the hardware implementation meets the requirements.
•	 Traceability is established between hardware requirements, the implementation, and the verification procedures and results.
•	Acceptance test criteria are identified, can be implemented and are consistent with the hardware design assurance levels of the hardware functions.
•	Omissions and errors are fed back to the appropriate processes for resolution.
2.5.5.2.	Verification Process Activities
Verification Process Activities are explained in the PL-HVVP-001-0002 The Hardware Validation and Verification Plan document.
2.5.6.	Validation and Verification Methods
Validation and Verification methods are explained in the PL-HVVP-001-0002 The Hardware Validation and Verification Plan document.
2.6.	 Configuration Management Process
The Hardware Configuration Management Process information is included in the PL-HCM-001-0002 Hardware Configuration Management Plan.
2.7.	 Process Assurance
The Process Assurance information is included in the PL-HPA-001-0002 Hardware Process Assurance Plan.
2.8.	 Certification Liaison Process
The purpose of the certification liaison process is to establish communication and understanding between the applicant and the certification authority throughout the hardware design life cycle to assist in the certification process.
2.8.1.	Communication Channels
The channels of communication for regular updates, inquiries, and discussions between the applicant and the certification authority will be specified. These will include email, meetings, teleconferences, and document sharing platforms.
2.8.2.	Documentation Exchange
The process for exchanging documentation and information between the applicant and the certification authority will be described. The format, frequency, and content of reports, submissions, and requests for information will be specified.
2.8.3.	Review Meetings
The frequency and format of review meetings between the applicant and the certification authority to discuss progress, milestones, and any issues or concerns related to the hardware design will be outlined.
2.8.4.	Issue Resolution
The process for resolving any issues or discrepancies identified during the certification process will be detailed. The steps for documenting, tracking, and closing out issues in a timely manner will be specified.
2.9.	Means of Compliance and Planning
The Plan for Hardware Aspects of Certification (PL-PHA-001-0004) for the 28VDC Battery defines the means of compliance of how the hardware for the 28VDC Battery will satisfy the certification basis. The PHAC also defines the hardware levels as determined by the system safety analysis process.
2.10.	 Compliance Substantiation
The substantiation of compliance will follow the steps outlined below:
2.10.1.	Certification Authority Reviews
Necessary documents and data will be provided for the reviews conducted by the certification authority.
2.10.2.	Document Submission
Documents required to confirm the hardware's compliance will be submitted to the certification authority. These documents will include the "Hardware Accomplishment Summary (HAS) and Top Level Drawing.
2.10.3.	Additional Document Submission
Other compliance data or evidence requested by the certification authority will be submitted.
2.11.	V-Model Development Approach
Design progress will be in line with and ARP4754 (Guidelines for Development of Civil Aircraft and Systems) and V-Model development life cycle progress will be applied. Sub-systems design will be in line with DO-254 (Design Assurance Guidance for Airborne Electronic Hardware). 
 
Figure 1 V Model Development Approach
The objective of the design and development process is to deliver ASPİLSAN Energy product’s design meeting the certification requirements and customer needs and ready for installation on the aircraft by meeting objectives on safety, reliability, quality, costs and schedule. Design Process is started either a request received from customer or a decision taken internally in ASPİLSAN Energy. When the design activity is started because of customer request, as required a business proposal will be prepared and a contract is signed by both Customer and ASPİLSAN Energy. Request by Customer can be received in any way such as e-mail, telephone, fax or formal requests. Design need might be any improvement/modification to existing product or a new product design.
2.12.	Relationship Between Processes and Activities
Relationship Between Process and Activities are given following figure.
 
Figure 2 Relationship between process and activities
2.13.	Means of Providing Feedback
This section outlines methods to facilitate feedback and interaction between hardware, system, and software processes throughout the design lifecycle. Essential mechanisms will include:
2.13.1.	Regular Meetings and Communication Channels
Software, hardware and systems teams will schedule meetings via the Outlook email system and ensure ongoing updates, encouraging ongoing dialogue between teams.
2.13.2.	Common Data and Document Sharing Platforms
JIRA, SVN and QDMS systems will be utilized as the shared data and document sharing platform for inter-team collaboration.
2.13.3.	Change Management and Version Control Systems
Change management and version control processes will be conducted through the JIRA system. Further details are provided in the PL-HCM-001-0002 Hardware Configuration Management Plan document.
2.13.4.	Error Tracking and Query Systems
All aspects of tracking design errors, version controls, change requests, and modification processes will be conducted through the JIRA system.
2.13.5.	Risk Management and Analysis Tools
Integration of tools facilitates proactive identification and mitigation of risks.
By specifying these mechanisms, effective feedback and interaction are ensured among hardware, system, and software processes, fostering collaboration and efficiency throughout the lifecycle. Details regarding risk management and analysis tools will be conducted according to the " PR-AV-003 Safety, Reliability, Maintainability, Testability Management Procedure " document.
2.14.	Planning Process
This Process describes how to determine the work plan including what resources are needed for the project.
2.14.1.	Planning Process Objectives
•	Hardware design life cycle processes are defined.
•	Standards to be held to are selected and defined.
•	The hardware development and verification environments are selected or defined.
•	The means of compliance of the hardware design assurance objectives proposed to the certification authority.
2.14.2.	Planning Process Inputs
•	Technical Requirements
•	Deadline
2.14.3.	 Planning Process Outputs
•	Design Plan
•	Project Schedule
•	Technical Team Organizational Chart
•	Project Management Plan
•	Risk Matrix
•	Hardware Configuration Management Plan
2.14.4.	 Planning Process Activities
Hardware Planning Process establishes the foundation for resource utilization and personnel assignments. During this process, the hardware development and integral activities are defined, and additional considerations are addressed. 
Entry criteria, activities, tools, outputs and exit criteria of the Hardware Planning Process are shown in the following table.

Table 5 Planning Process Activities
Entry Criteria	Activities	Tools	Outputs	HCM Storage	Exit Criteria
• Project costs, schedule, resources approved
• Certification basis and CRIs defined based on related Standards
• System architecture is defined
• Peer review records available
• Problem reports written to update plans or standards	• Prepare or update hardware plans and hardware standards	• Word
• Excel
• PowerPoint
• JIRA
• PHAC
• HDP
• HVVP
• HPAP
• HCMP 
• PHAC and HCMP released
• HDP, HVP, HPAP, HCMP controlled in CM
• Hardware plans released
• Hardware standards released
2.14.5.	Planning Process Tools Usage
Planning process tools are given Table 5.
2.14.6.	Planning Process Transition Criteria
Planning process transition criteria is given Table 5.
2.15.	Development Flow Diagrams
2.15.1.	Analog Hardware Development Flow
Development flow is as in Figure 2.
2.15.2.	Complex Hardware Development Flow
Complex Hardware development plan will be described in PHAC if the design is complex.
2.16.	Requirements Capture Process
Requirement capture process will be covered mainly following types of requirements (as described in SAE-ARP 4754A);
•	Safety Requirements
•	Functional Requirements
•	Customer Requirements
•	Operational Requirements
•	Product Specifications Requirements
•	Performance Requirements
•	Interface Requirements
•	Physical and Installation Requirements
•	Maintainability Requirements
•	Environmental Test Requirements
•	Human Factor Requirements
•	Additional Certification Requirements
•	Derived Requirements
•	Re-use of Existing Certificated Systems and Items  
•	Integrated Logistic Support Requirements
2.16.1.	Requirements Capture Process Objectives
Requirement capture process objectives are: 
•	Requirements are identified, defined and documented. This includes allocated requirements from the PSSA and all requirements from the System Safety Assessment. 
•	Derived requirements produced are fed back to the system safety process.
•	Requirement omissions and errors are provided to the appropriate process for resolution.  
2.16.2.	Requirements Capture Process Inputs
•	Hardware Design Plan. (This Document)
•	Hardware Requirement Standard 
•	Baselined System Requirements
•	Safety Requirements from “RP-PSSA-001-0001 Preliminary System Safety Assessment”
•	System Architecture
2.16.3.	Requirements Capture Process Outputs
•	Requirements baseline export
•	Hardware Requirements Document
•	Problem report for upper level requirement errors and omissions.
2.16.4.	Requirements Capture Process Activities
•	Analyzing the requirements functionality and architectural considerations 
•	Documentation of the hardware requirements from “RP-PSSA-001-0001 Preliminary System Safety Assessment” process.
•	Defining derived requirements for implementation purposes, including low-level requirements.
•	Feeding back the derived requirements to SSA defined 
•	Documenting all data related to the requirements capture process, including low-level requirements.
•	Providing the requirement omissions and errors to “PR-AV-008 Hardware Requirement Standard”.
•	Identifying and tracing all requirements, including low-level requirements, to higher-level requirements in the DOORS platform.
2.16.5.	Requirements Capture Process Tool Usage
Requirements capture process tools are listed below.
•	Word 
•	Excel 
•	DOORS
2.16.6.	Requirements Capture Process Transition Criteria
•	System functions are released.
•	Hardware functions are released.
•	RVTM is released.
2.17.	Conceptual Design Process
The conceptual design process generates a high-level design concept that can be evaluated to determine the likelihood that the final design implementation will satisfy the requirements. The conceptual design documents are defined in PHACs and the configuration of these documents is kept according to the " PL-HCM-001-0002 Hardware Configuration Management Plan".
The conceptual design process will be carried out accordance with DO-254.
2.17.1.	Conceptual Design Process Objectives
The conceptual design objectives are: 
•	The conceptual design of the hardware item is developed in accordance with its requirements. 
•	Derived requirements produced are processed as described in “Requirement Capture”.
•	Requirement omissions and errors are processed as described in “Requirement Capture”.
2.17.2.	Conceptual Design Process Inputs
Conceptual design process inputs are summarized in the below.
•	Hardware Design Plan (This document)
•	Hardware Configuration Management Plan
•	Equipment Requirements Document
•	Hardware Requirements Document
•	Peer review records available
•	Problem reports written to update conceptual design
2.17.3.	Conceptual Design Process Outputs
Conceptual design process outputs are summarized in the below.
•	Block diagrams
•	Architecture descriptions
•	Mechanical sketches
2.17.4.	Conceptual Design Process Activities
Conceptual design process activities are summarized in the below.
•	Create or update top level representation of the design,
•	Functional elements mapped to circuit elements,
•	Identify errors or omissions in upper level requirements.
2.17.5.	Conceptual Design Process Tools Usage
Conceptual design process tools are listed below.
•	Word
•	Excel
•	PowerPoint
•	Jira
•	Draw.io
2.17.6.	Conceptual Design Process Transition Criteria
•	Conceptual design released 
•	Design architecture released,
•	Requirements updated,
•	Updated RVTM released
•	Conceptual design related documentations released
2.18.	Detailed Design Process
The detailed design process produces a detailed design concept that may be assessed to determine the potential for the resulting design implementation to meet the low-level requirements. This may be accomplished using such items as functional block diagrams, design and architecture descriptions, circuit card assembly outlines, and chassis sketches.
The detailed design process will be carried out accordance with DO-254.
2.18.1.	Detailed Design Process Objectives
The detailed design objectives are: 
•	The hardware item detailed design is developed consistent with its high-level requirements and conceptual design data. 
•	Derived requirements produced are fed back to the conceptual design or other appropriate processes. 
•	Requirement omissions and errors are provided to the appropriate processes for resolution.
2.18.2.	Detailed Design Process Inputs
Detailed design inputs are:
•	Hardware functions 
•	System requirements and derived hardware requirements
•	Hardware interfaces
•	System architecture
•	Hardware architecture 
•	Hardware architecture rationale
•	Hardware constraint
2.18.3.	Detailed Design Process Outputs
Detailed design process outputs are summarized in the below.
•	Hardware design data
o	Design diagram
o	Schematic 
o	Circuit design and layout constraints 
o	Bill of materials
o	Assembly drawings
•	Acceptance test criteria 
•	Problem report for high level requirements errors or omissions
2.18.4.	Detailed Design Process Activities
Detailed design process activities are summarized in the below.
•	Create or update circuit elements for all functional elements,
•	Create hardware design
•	Optimize hardware design 
•	Create or update trace data for all circuit elements 
•	Define hardware constraints
•	Select components in accordance with the ECMP
•	Test methods and hardware-software interface data
•	An assessment of unused functions will be performed to identify potential effects on safety. Adverse effects will be addressed in test reports.
•	Architectural design techniques should be implemented as necessary. These may include establishing safety monitors for proper functionality, dissimilarity between function and safety monitors, preclusion of a design error from impacting safety, and fault tolerant designs. 
•	Derived requirements produced during the detailed design process will be fed back to the conceptual design or other appropriate processes.
•	Requirement omissions and errors discovered during the detailed design process will be provided to the appropriate process for resolution. 
2.18.5.	Detailed Design Process Tools Usage
Detailed design process tools are listed below.
•	Altium
•	Word
•	Excel
•	Simulation tools
2.18.6.	Detailed Design Process Transition Criteria
•	Detailed design released,
•	Hardware Design Data released,
•	Requirements updated,
•	Updated RVTM released,
•	Detailed design related documentations released
•	Acceptance Test Criteria defined
2.19.	Implementation Process
2.19.1.	Implementation Process Objectives
The purpose of the Implementation process is to create or fabricates a system element conforming to that element’s detailed description. The element is constructed ASPİLSAN Energy’s technologies and practices.
During the implementation process, engineers follow the requirements allocated to the system element to fabricate, code, or build each induvial element using specified materials, processes, physical or logical arrangements, standards, technologies and/or information flows outlined in detailed drawings or other design documentation.
2.19.2.	Implementation Process Inputs / Outputs
Inputs and outputs for the requirement process are listed below.
 
Figure 3 Implementation Process Input / Output
2.19.3.	Implementation Design Process Activities
The systems requirement process includes the following activities:
•	Prepare for Implementation
o	Define fabrication/coding procedures, tools and equipment
o	Elicit from stakeholders, developers, and teammates any constraint imposed by implementation technology, strategy, or enabling systems.
o	Document the plan
•	Perform Implementation
o	Develop data for training users on correct and safe procedures for operating and maintaining that element, either as a stand-alone end item or as part of a larger systems.
o	Complete detailed product, process, material specifications
o	Ensure the realization of the system element
o	Prepare initial training capability and draft training documentation
o	Prepare a hazardous materials log
o	Determine the packaging
•	Manage Results of Implementation
o	Identify and record the results
o	Record any anomalies
o	Establish and maintain traceability
o	Provide baseline for configuration management.
2.19.4.	Implementation Process Tools Usage
Implementation process tools are listed below.
•	Altium
•	Word
•	Excel
2.19.5.	Implementation Process Transition Criteria
Implementation process transition criteria are listed below.
•	Peer reviews complete, all issues resolved
•	Assembly drawing
•	Gerber files released
2.20.	Production Transition Process
2.20.1.	Production Transition Process 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.
2.20.2.	Production Transition Process Inputs
Production transition process inputs are listed below.
•	Completed development
•	Assembly drawing
•	Gerber files
•	Production files
2.20.3.	Production Transition Process Outputs
Production transition process outputs are listed below.
•	Populated and tested printed circuit cards
•	Hardware accomplishment summary (HAS)
•	Problem Report for high level requirements errors or omissions
2.20.4.	Production Transition Process Activities
Production transition process activities are listed below.
•	Create hardware production.
•	Create or update HAS through CM.
•	Complete reviews.
•	Identify errors or omissions in high level requirements.
2.20.5.	Production Transition Process Tools Usage
Production transition process tools are listed below.
•	Jira
•	Word
•	Excel
•	Hardware production equipment
2.20.6.	Production Transition Process Transition Criteria
•	Peer reviews complete
•	All issues resolved
•	HAS released through CM
3.	HARDWARE PRODUCT DESCRIPTION
System hardware block diagram and detailed design information will be found in BL-SD-001-0002 System Description Document and “PL-PHA-001-0004 Plan for Hardware Aspect of Certification 28 VDC Battery”.
3.1.	      28 VDC Battery
“28 VDC Battery” is an LRU for Power Storage System of A/C EPS.
3.1.1.	Hardware Specifications To Be Achieved
Specifications of the 28 VDC battery are specified in “BL-SD-001-0002 System Description Document” as requirements and related requirements are assigned to hardware in Hardware Requirement Document and detailed in “PL-PHA-001-0004 Plan for Hardware Aspect of Certification 28 VDC Battery”
3.1.2.	Alternative Uses of 28 VDC Battery
There is no planned alternative use of 28 VDC Battery.
3.1.3.	Planned Service Life for 28V VDC Battery
In order to extend the life of the product, the product will be designed to be used at the best possible performance and the terms of use and storage conditions will be communicated to the Customer to increase its performance. The hardware materials selected will be selected to provide the best possible lifespan, and the hardware will be optimized to provide the best lifespan.
3.1.4.	Upgrade Considerations for 28V VDC Battery
Performance improvements and fixes of various hardware bugs for the 28V DC battery will be managed by creating hardware change requests (HCRs) using JIRA. Detailed information will be include about the management of this process in the “PL-HCM-001-0002 Hardware Configuration Management Plan” document.
4.	HARDWARE DESIGN METHODS
Hardware design methods will be conducted according to the DO-254.
4.1.	Design Policies And Standards
The design and development activities of the products are carried out according to “PR-AV-001 Design Procedure (Aviation)” and the following standards:
•	Hardware Design Standard (PR-AV-007)
•	Hardware Validation and Verification Standard (PR-AV-009)
•	Hardware Requirement Standard (PR-AV-008)
4.2.	Requirements Capture and Specification Methods
System requirements are the foundation of the system definition and form the main architecture, design, integration and verification. Each requirement carries cost and time. Thus, changes in requirements later in the development phase change have significant cost impact on the project, possible resulting in collation.
The hardware design process begins with a meticulous analysis of system and safety requirements. These requirements are captured through collaboration with system engineers, stakeholders, and domain experts. A combination of interviews, workshops, and document reviews is used to ensure a comprehensive understanding of functional, performance, and safety requirements. Captured requirements are documented using industry-standard formats and traceability tools, maintaining clear links between system and hardware requirements.
4.3.	Conceptual Design
The conceptual design process involves establishing the foundational framework for the development of airborne electronic hardware. High-level architectural decisions, defining partitions and interfaces, addressing safety considerations, selecting appropriate technologies, and documenting these aspects rigorously are performed during conceptual design. This phase sets the direction for the hardware development process, ensuring that safety, reliability, and compliance requirements are integrated from the very beginning.
4.4.	Detailed Design
The hardware design is taken from conceptual design to concrete, detailed specifications during detailed design process. Design improvements, reconsiderations, creating individual partitions, specifying interfaces, safety analysis and producing extensive documentations are performed during detailed design process. This phase ensures that the hardware is designed with precision and in alignment with DO-254's stringent safety and quality requirements.
 
Figure 4 Hardware Design Process Flow Graph
4.5.	Synthesis Techniques
Synthesible RTL, FPGA, logic design is not used in this project. This section is not applicable.
4.6.	Implementation
Detailed design data is turned into functional hardware parts while sticking to safety and quality features during implementation process. Coding, layout design, component selection, configuration management, tool qualifications, timing closures and extensive documentations are performed in this process. This phase ensures that the hardware is realized with precision, meets performance targets, and fulfills the stringent safety requirements of DO-254 and the hardware is ready to be tested.

4.6.1.	Architectural Mitigation Management for DAL A and DAL B Functions
If applicable, DAL A and DAL B functions are stated on PSSA and created FFPA report shows the sore points of the design. Considering the FFPA results, sore points in design will be resolved by one or more following methods:
•	Design redundancy is provided via backup designs for the relevant function.
•	Design fail tolerance is provided via improvements on the design.
•	Fail safe designs is implemented for appropriate functions.
•	COTS parts are replaced with equivalent parts with better MTBF and FIT values.
4.7.	Production Transition
The production transition method involves a set of well-defined processes and procedures to ensure the smooth transition from hardware development to production. This phase includes reviews, documentation checks, production planning, configuration management, process validation, supplier control, and ongoing monitoring to guarantee that the produced hardware meets the safety and quality features.

5.	HARDWARE DESIGN ENVIRONMENT
5.1.	Hardware Development and Verification Tools
The software tools for hardware design is detailed in “PL-PHA-001-0006- Plan for Hardware Aspects of Certification 28 VDC Battery”.
A.E. uses following hardware tools for hardware design;
•	DC Power Supply
•	DC Electronic Load
•	Oscilloscope
•	Multimeter
•	Thermal Camera etc.
5.2.	Programming Languages
There is no programming language usage during hardware design process.
6.	HARDWARE ITEM DATA
6.1.	Hardware Design Data
Hardware Design data will be generated according to ASPİLSAN Energy design, configuration and quality procedures. These procedures have been reviewed to ensure alignment with the requirements of DO-254 for hardware design data. This includes maintaining traceability between system requirements and design outputs, implementing appropriate design verification methods (analysis, simulation, testing), and employing a robust configuration management system for all design data.
6.2.	 Design Documents and Files To Be Produced
6.2.1.	Block Diagram of Design Architecture
This document contains general technical information about electrical design. Functions from System Description Documents (see Table 1) are assigned to units in this document.
6.2.2.	Schematic Document
This document contains all the board level circuitry but not the board drawings.
6.2.3.	PCB File
This file is created based on the information of schematic file. It contains all the PCB data, including electrical connections and component placements.
6.2.4.	Gerber File
This file contains all the layer images of the PCB and mechanical holes such as; screw holes, through hole component holes, vias. The document is submitted to PCB manufacturer.
6.2.5.	Pick & Place File
This file is produced to be submitted to PCBA responsible. The file contains component placement data for PCBA process.
6.2.6.	Draftsman Document
There are two different draftsman document types created in AE.
6.2.6.1.	PCB Manufacturing Draftsman
This document contains additional information about PCB manufacturing and is meant to be submitted to PCB manufacturer. The additional informations are listed below:
•	PCB and silk screen color.
•	PCB layer thicknesses.
•	PCB material information.
•	Panel information.
•	Stencil information.
6.2.6.2.	PCBA Draftsman
PCBA draftsman document is to be submitted to PCBA responsible and contains instructions for PCBA process.

7.	ADDITIONAL CONSIDERATIONS
7.1.	Use of Previously Developed Hardware
There is no previously developed for this project. This plan covers the new development approach of ASPİLSAN Energy for this project.
7.2.	Interaction Among Processes
All design activities will be performed according to AE internal “Design Procedure (Aviation) - PR-AV-001” and in line with ARP4754 and DO-254.
 
7.3.	 Planned Process Technology Options
Selecting the appropriate process technology for hardware design is a critical decision that affects the performance, reliability, and manufacturability of the hardware component. Process technology options are evaluated based on factors; feature size, power consumption, process speed, environmental tolerance, and obsolescence risks. The chosen process technology should meet the specified requirements while considering the long-term availability and support required for avionics applications. Requirements will be met are declared in Equipment Requirements Document, Hardware Requirement Document and “RP-SSA-001-0001 Preliminary System Safety Assessment” design options and process will be followed as described in “PR-AV-007 Hardware Design Standard”.
7.3.1.	Use of Commercial-Off-The-Shelf (COTS) Components and Microprocessors
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. (Electronic Component Management Plan).
7.4.	 Assembly and Use Options
The hardware design includes defining the component's assembly processes and use conditions. Options for assembly include the selection of appropriate manufacturing techniques, soldering techniques, and interconnection technologies. Use conditions consist of environmental factors such as temperature, humidity, and vibration to which the hardware will be exposed throughout its operational existence. These considerations ensure that the hardware component will continue to be reliable and functional in its intended life and aircraft environment.
7.5.	Product Packaging
Product will be put in its own custom designed package for delivery and shipment.
7.6.	 Hardware Mounting Options
The mounting options are evaluated based on factors such as structural integrity, vibration isolation, thermal dissipation, and accessibility for maintenance and replacement. The chosen mounting method should ensure the component's stability and reliability throughout its operational life.
7.7.	 Safety Considerations
Safety Considerations are detailed within RP-PSSA-001-0001 Preliminary System Safety Assessment.
7.8.	Design Assurance Considerations
SAE ARP4761, Guidelines and Methods for Conducting the Safety Assessment Process on Civil Airborne Systems and Equipment, as a source of safety assessment methods to be used in the hardware design assurance process.
7.9.	Deviations and Modifications to Plans
If there are deviations or modifications in the plans, ASPİLSAN Energy will inform TA as PL-HCM-001-0002 Configuration Management Plan defined."
Bu Hardware Design plan dokumanı aşağıdaki soruların cevaplarını içeriyor mu ? içeriyorsa eğer soruların cevapları dokumanın hangi sectionda olduklarını yaz. Sorular aşağıdadır;
1.4.1	If the HDP is followed, will the applicable DO-254 design processes objectives be met?
1.4.2	Does the HDP adequately address the proposed contents described in DO-254, Section 10.1.2? If not, are the contents included in another plan?
1.4.3	Are the hardware design processes defined in sufficient detail to ensure proper implementation of the hardware life cycle processes and model proposed for the project? Are transition criteria clear and enforceable?
1.4.4	Will applicable aspects of the HDP, development environment, standards and processes 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.4.5	"Has the hardware development environment been adequately defined (e.g., documentation tools, requirements definition and capture tools, traceability tools, design tools (including architecture, derived requirements definition and capture tools, HDL coding tools, integration tools, development host computer environment, tools to ensure protection of baselined hardware life cycle data such as configuration management and control tools, access privileges, etc.)? Additionally:
• Are tool users’ guides, restrictions, and limitations available and known by the hardware developers using them?
• Do any of the tools support enforcement of the hardware description languages (HDL) standards, transition criteria, data baselining and approval process, etc.? For example: (1) does the HDL code editor tool or compiler enforces any coding rules, restrictions, or limitations? (2) does the document control (CM system) enforce access privileges to data and ensure no unauthorized changes to baselined data?"
1.4.6	"What kind of synthesis tool is being proposed? Does the applicant have experience with the synthesis tool? Have the synthesis tool’s options and optimization been identified? Have the errata sheets, vendor problem notices bulletins, or vendor problem reports for the synthesis tool been reviewed and analyzed for safety impact on the operation of the tool? If safety impacts have been identified, then have the mitigations been implemented and documented for the synthesis tool?

Note: Changes to synthesis tool’s options and optimization may invalidate previous tests and coverage analysis."
1.4.7	"Are HDL coding and design standards defined?

Note: Some HDL constructs may produce non-deterministic results and therefore may not meet the objectives of DO-254."
1.5	Review the HCMP and consider the following questions:
1.5.1	If the HCMP is followed, will the applicable DO-254 configuration management objectives be satisfied?
1.5.2	Does the HCMP adequately address the proposed contents described in DO-254, Section 10.1.5?
1.5.3	Will applicable aspects of the HCMP, 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?