"
TURKISH LIGHT UTILITY HELICOPTER
LITHIUM ION BATTERY


PL-PHA-001-0005


PLAN FOR HARDWARE ASPECTS OF CERTIFICATION



CDRL ID: TLUH-BAT-SoW-117



ASP2206102



DOCUMENT APPROVAL/AUTHORIZATION
PREPARED BY
NAME	TITLE/ROLE	REV	SIGNATURE
Fikret YILDIRIM 	Hardware Design Engineer	1	

CONTRIBUTERS
NAME	TITLE/ROLE	REV	SIGNATURE
Emine KOCAÖZ	Safety and Reliability Engineer	1	
Anıl GENÇTÜRK	Hardware Design Engineer	1	
Aybüke TAŞDEMİR	System Engineering	1	

APPROVED BY
NAME	TITLE/ROLE	REV	SIGNATURE
Eren ERDOĞAN	Hardware Design Engineer	1	

AUTHORIZED BY
NAME	TITLE/ROLE	REV	SIGNATURE

Nedim Uğur BAKOĞLU	
Battery Development Manager	1	


 
REVISION LIST
Order	Para. No	Page	Comments	Date	Rev.	Revised
1	-	-	Initial Release	<DOC_HAZ_TAR>	0	-
2	-	-	GG-1248	DOC_HAZ_TAR>	1	Fikret YILDIRIM

 
No.	Department	Name	Descriptions
1	Project Management	ASPİLSAN Energy	Internal Distribution in Electronic Environment
2	Design and Development	ASPİLSAN Energy	Internal Distribution in Electronic Environment
3	Quality and Certification	ASPİLSAN Energy	Internal Distribution in Electronic Environment
4	Production	ASPİLSAN Energy	Internal Distribution in Electronic Environment
5	Customer	Turkish Aerospace	External Distribution in Electronic Environment
DISTRIBUTION LIST	





 
Table of Contents
1	PURPOSE	1
2	SCOPE	1
3	APPLICABLE DOCUMENTS	1
3.1	Internal References	1
3.2	External References	2
3.3	Acronyms, Abbreviations and Symbols	2
4	INTRODUCTION	7
4.1	Special Considerations Cross Reference	7
4.2	Team Members and Signature Authority	8
4.2.1	Independent Reporting Structure	8
5	SYSTEM OVERVIEW	9
5.1	System Top Level Diagram	9
5.1.1	System Functions Allocated to Electrical Hardware and Software	10
5.1.2	Hardware and Software Interfaces	20
5.1.3	Executive Summary	21
5.1.4	System Failure Conditions	23
5.1.5	High-Level Hardware Functions and Contribution to Potential Failures	23
6	HARDWARE OVERVIEW	24
6.1	Hardware Architecture	24
6.1.1	BMB	26
6.1.1.1	Microcontroller Unit	28
6.1.1.2	BMB Power Supply	28
6.1.1.3	Input Line filter And Hold-Up	28
6.1.1.4	ARINC429 Line Drive	28
6.1.1.5	Isolated Discrete Input	28
6.1.1.6	Isolated Discrete Output	29
6.1.1.7	Data Logging	29
6.1.1.8	Communication Isolation	29
6.1.1.9	Analogue SOC	29
6.1.1.10	Pack Monitoring	29
6.1.1.11	Led Driver	29
6.1.1.12	Module Enable	30
6.1.2	Modules	30
6.1.2.1	Monitor Board	30
6.1.2.2	Control Board	35
6.1.2.3	Module Cells	38
6.1.2.4	Module Heater	38
6.1.2.5	Cell Temperature Sensors	39
6.1.3	Battery Status Indicator	39
6.1.4	Analogue RTD	39
6.2	Architecture Mitigation	39
6.3	Hardware Fault Management	40
6.3.1	Fault Tolerance	40
6.3.2	Fail Safe	41
6.4	Hardware Functions	42
6.5	Hardware Items	45
6.6	New Technologies to Be Used	58
6.7	Hardware Safety, Redundancy and Partitioning	59
6.8	Single Event Upset Planning	59
6.8.1	Initial Assessment	60
6.8.2	SEU Analysis	60
6.8.3	Qualitative assessment process	60
6.8.4	Quantitative assessment process	60
7	CERTIFICATION CONSIDERATIONS	61
7.1	Certification Basis	61
7.2	Hardware Level Determination	61
7.3	Hardware Means of Compliance	61
8	HARDWARE DESIGN LIFECYCLE	62
8.1	Team Member Responsibilities	62
8.2	Processes	62
8.3	Design Procedures	63
8.4	Hardware Design Methods	63
8.5	Hardware Standards	64
8.6	Activities	65
9	HARDWARE DESIGN LIFECYCLE DATA	65
9.1	Trace Data	67
10	ADDITIONAL CONSIDERATIONS	68
10.1	Use of Previously Developed Hardware	68
10.2	Data to Be Reused	68
10.3	Use of Commercial-Off-The-Shelf (COTS) Components	68
10.4	Modifiable Devices	68
10.5	Simple Electronic Hardware (SEH)	69
10.6	Commercial Off-The-Shelf (COTS) Microprocessors	70
10.7	Design Assurance Considerations	70
10.8	Tool Assessment and Qualification	70
10.9	Hardware Tool Assessment and Qualification Process	73
10.10	Hardware Tool Assessment and Qualification Data	73
10.11	Use of Suppliers, Sub-Tier Suppliers and Off-Shore Facilities	73
10.12	Deviations and Modifications to Plans	73
11	ALTERNATIVE METHODS	73
12	CERTIFICATION SCHEDULE	74
12.1	Stage of Involvement Audits and Project Milestones	74
APPENDIX A: DO-254 COMPLIANCE MATRIX	75
APPENDIX B: AC-20-152 COMPLIANCE MATRIX	77



 
List of Tables
Table 1 Applicable Documents	1
Table 2 Reference Documents	2
Table 3 Definitions	2
Table 4 Abbreviations	5
Table 5 Special Considerations Cross Reference	7
Table 6 System Functions Allocated to Electrical Hardware and Software	10
Table 7 High-Level Hardware Functions and Contribution to Potential Failures	23
Table 8 Each module cell configuration details	30
Table 9  Hardware Functions	42
Table 10 Hardware COTS Items	45
Table 11 AEH Certification Memorandums	61
Table 12 Hardware Control Categories	65
Table 13 Tools to Use	71

 
List of Figures
Figure 1 ASPİLSAN Enerji Organization Chart	8
Figure 2 Battery Top Level Diagram	10
Figure 3:TMS320F28377S Functional Block Diagram	22
Figure 4 Pre-design architecture of lithium ion battery	25
Figure 5 Battery Management Board Block Diagram	27
Figure 6 Monitor Board Block Diagram	31
Figure 7 Control Board Block Diagram	36
Figure 8 Design and Verification Tool Assessment and Qualification	71


 
 

1	PURPOSE
This plan describes the procedures, methods and standards to be applied and the processes and activities to be carried out for the certification of the battery hardware used by the Turkish Light Utility Helicopter Program - Ata 24 Electric Power System Battery Subsystem.
2	SCOPE
This plan defines the approach for the hardware aspects of certification for Battery utilized by Turkish Light Utility Helicopter - Ata 24 Electrical Power System Battery Subsystem.
3	APPLICABLE DOCUMENTS
3.1	Internal References
Table 1 Applicable Documents
Document No	Title
BL-SD-001-0003	System Description Document
BL-IC-001-0003	Interface Control Document
PL-DO-001-0004	Design Organization Interface Document
RP-PSSA-001-0003	Preliminary System Safety Assessment
PL-HPA-001-0003	Hardware Process Assurance Plan
PL-HD-001-0003	Hardware Design Plan
PL-HVVP-001-0003	Hardware Validation Verification Plan
PL-HCM-001-003	Hardware Configuration Management Plan
PL-ECMP-001-0001	Electronic Component Management Plan
PR-AV-001	Design Procedure (Aviation)
PR-AV-007 	Hardware Design Standard
PR-AV-008 	Hardware Requirement Standard
PR-AV-009 	Validation Verification Standard
PR-AV-0010	Hardware Archive Standard
PL-PSA-001-0005	Plan for Software Aspect of Certification

3.2	External References
The documents listed in Table 2 Reference Documentsbelow is for reference only. Each document is applicable to this document only to the extent specified herein.
Table 2 Reference Documents
Document No	Title
RTCA/DO-254A	Design Assurance Guidance for Airborne Electronic Hardware
AMC 20-152A	Development Assurance for Airborne Electronic Hardware (AEH)
MIL-HDBK-516C	Department of Defence Handbook: Airworthiness Certification Criteria
MIL-STD-704F	Department of Defence Interface Standard: Aircraft Electric Power Characteristics
3.3	Acronyms, Abbreviations and Symbols
Definitions which are used in the PHAC are shown in Table 3 
Table 3 Definitions
Definitions	Description
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.
Battery Pack	Final shape of battery system. Composed of module, BMB, interfaces, etc.
Board	It is a term used to describe electronic cards or circuit boards. This term refers to a substrate or carrier on which electronic components are mounted, bonded or integrated.
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.
Common Cause Analysis	Generic term encompassing zonal safety analysis, particular risk analysis, and common mode analysis.
Cell	Most important unit of battery that transform chemical energy to electrical energy or vice versa. They are composed of cathode, anode, separator and electrolyte. 
Common Mode Analysis	An analysis performed to verify that failure events identified in the ASA/SSA are independent in the actual implementation.
Complexity	An attribute of functions, systems or items, which makes their operation, failure modes, or failure effects difficult to comprehend without the aid of analytical methods.
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.
Demonstration	A method of proof of performance by observation.
Derived Requirements	Additional requirements resulting from design or implementation decisions during the development process which are not directly traceable to higher-level requirements.
Failure	An occurrence which affects the operation of a component, part or element such that it can no longer function as intended,
Fault	A manifestation of an error in an item or system that may lead to a failure.
Hardware	An item that has physical being.
Hazard	A condition resulting from failures, external events, errors, or combinations thereof where safety is affected.
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.
Model	An abstract representation of a given set of aspects of a system/function/item that is used for analysis, simulation and/or code generation and that has an unambiguous, well defined syntax and semantics.
Redundancy	Multiple independent means incorporated to accomplish a given function.
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.
Risk	The combination of the frequency (probability) of an occurrence and its associated level of severity.
Module	It is a modular unit consisting of a Monitor Board, Control Board, heater and cell thermistors, consisting of multiple cells configured in serial and parallel.
Safety	The state in which risk is acceptable.
Software	Computer programs, procedures, rules, and any associated documentation pertaining to the operation of a computer system.
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.
Validation	The determination that the requirements for a product are correct and complete.
Verification	The evaluation of an implementation of requirements to determine that they have been met.
The following acronyms and abbreviations may have been used in this document at 

Table 4.


Table 4 Abbreviations
Abbreviations, Acronyms or Terms	Definition
%	Percentage
AEH	Airborne Electronic Hardware
A	Ampere
A/D – D/A Converter	Analogue to Digital – Digital to Analogue Converter
ADC	Analogue to Digital Converter
Ah	Ampere Hour
AOT	Analogue Overt Temperature Protection
ARINC	Aeronautical Radio, Inc
BMB	Battery Monitor Board
BOL	Beginning of Life in Regards to Initial Battery Capacity
CDR	Critical Design Review
CEH	Complex Electronic Hardware
COTS	Commercial Off-The-Shelf
COV	Cell Overvoltage Charge Protection
CUV	Cell Undervoltage Discharge Protection
DAC	Digital to Analog Converter
DAL	Design Assurance Level
DC	Direct Current
DOID	Design Organization Interface Document
ECMP	Electronic Component Management Plan
EOL	End of Life in Regards to Final Battery Capacity
FFP	Functional Failure Path
FHA	Functional Hazard Assessment
HC1 and HC2.	Hardware Control Categories 1 and 2.
HCMP	Hardware Configuration Management Plan
HDP	Hardware Design Plan
HDS	Hardware Design Standards
HPAP	Hardware Process Assurance Plan
HVVP	Hardware Validation Verification Plan
I2C	Inter-Integrated Circuit
LRU	Line-Replaceable Unit
MCU	Micro Controller Unit
MOV	Modul Overvoltage Protection
MUV	Modul Undervoltage Protection
N/A	Not applicable
NTC	Negative Temperature Coefficient
OCD	Overcurrent Discharge Protection
OTC	Overtemperature Charge Protection
OTD	Overtemperature Discharge Protection
PCB	Printed Circuit Board
PHAC	Plan for Hardware Aspect Certification
PLATFORM	Data Concentration Unit
PSAC	Plan for Software Aspect of Certification
PSSA	Preliminary System Safety Assessment
PTC	Positive Temperature Coefficient
RTC	Real Time Clock
RTCA	Radio Technical Commission for Aeronautics
RTD	Resistance Temperature Detectors
SCD	Short Circuit Discharge Protection
SEH	Simple Electronic Hardware
SOC	State of Charge
SOH	State of Health
SPI	Serial Peripheral Interface
TA	Turkish Aerospace
TLUH	Turkish Light Utulity Helicopter
UART	Universal Asynchronous Receiver / Transmitter
V / mV	Volt / millivolt
Y/N	Yes/No

4	INTRODUCTION
4.1	Special Considerations Cross Reference
Table 5 Special Considerations Cross Reference
Hardware Consideration	Applicable (Y/N)	Addressed in Doc / Section
Complex Electronic Hardware (CEH)	 N	N/A
Simple Electronic Hardware (SEH)	Y	6.5
Product Service History	N	N/A
Legacy System Hardware	N	N/A
Previously Developed Hardware	N	N/A
Field Loadable Hardware	N	N/A
Option-Selectable Hardware	N	N/A
User-Modifiable Hardware	N	N/A
Safety Monitoring Hardware	N	N/A
COTS Hardware	Y	6.5
IP Cores	N	N/A
HDL Libraries	N	N/A
Board Support Package	N	N/A
Parameter Data / Databases	N	N/A
Dead, Unreachable or Deactivated HDL	N	N/A
DAL Justification	Y	7.2
Elemental Analysis (HDL Coverage)	N	N/A
Partitioning (Multi-DAL)	Y	6.7
Exhaustive Input Testing	N	N/A
Development Tool Qualification	N	N/A
Verification Tool Qualification	N	N/A
Single Event Upset (SEU)	Y	6.8
Formal Methods	N	N/A
Domestic / Off-Shore Supplier	N	N/A
International Cert (EASA, TCCA, etc.)	N	N/A
Functional Failure Path Analysis (FFP)	Y	6.7
Safety-Specific Analysis	N	N/A
Architectural Mitigation	Y	6.2
Open Problem Report Management	Y	PL-HCM-001-0003 Hardware Configuration Management Plan
Issue Papers / Certification Review Items	N	N/A
4.2	Team Members and Signature Authority
Team members and signature authority are defined in PL-DO-001-0004 DOID.
4.2.1	Independent Reporting Structure
The following chart shows that the Quality Assurance Organization is independent from Engineering. It also demonstrates that the verification and test activities are performed independently by someone other than the development engineer. 
5	SYSTEM OVERVIEW
5.1	System Top Level Diagram
Lithium ion battery is a Line Replaceable Unit (LRU) for ATA 24 Electrical Power System of TLUH Platform. The lithium ion battery provides electrical power to helicopter during ground operations including the engine start pre-flight checks and during an emergency condition. Battery is also used for supplying DC electrical power to both control and ignition equipment and to start turbine engines of a twin-engine helicopter. Battery supports helicopter electrical power source during start operation of loads that have high starting currents. The The lithium ion battery will be developed to meet all equipment requirements. Equipment requirement document will be prepared. The  system functions of the lithium ion battery are defined as in Table 6.
 The lithium ion battery shall have two different electrical connections. Battery top level block digram is shown in Figure 2. One is employed for power delivery during charging and discharging operations that is connected to electrical power system platform. Charging and discharging will be done from the same power connector. Second, the communication connector of the battery is reserved for communication with the platform to report critical data and receive commands for battery control operations. Detailed information such as power connector, communication connector and pinouts are explained in BL-IC-001-0003 Interface Control Document.

5.1.1	System Functions Allocated to Electrical Hardware and Software
System level and high-level hardware and software functions for lithium ion battery are as in Table 6.
Table 6 System Functions Allocated to Electrical Hardware and Software
Functions	Allocation	Circuit Board	COTS(Y/N)
Provide 28VDC Electrical Power 	 	 	
Sense Battery Current	Hardware	BMB	Y
Read Battery Current 	Software	BMB	Y
Load Detect Algorithm	Software	BMB	Y
Provide Input Signals to Discharge Switching Circuits	Software	BMB	Y
Provide Input Signals to Discharge Switching Circuits	Hardware	BMB	N
Control Discharge Switching Elements	Hardware	Module	Y
Accept Electrical Power to Get Charged	 	 	 
Sense Battery Current	Hardware	BMB	Y
Read Battery Current 	Software	BMB	Y
Charge Detect Algorithm	Software	BMB	Y
Provide Input Signal to Charge Switching Circuits	Software	BMB	Y
Provide Input Signal to Charge Switching Circuits	Hardware	BMB	N
Control Charge Switching Elements 	Hardware	Module	Y
Provide Cell Over Voltage (COV) Protection	 	 	 
Sense Cell Voltages	Hardware	Module	Y
Read Cell Voltages 	Software	BMB	Y
Implement COV Protection	Hardware	Module	Y
Implement COV Protection Algorithm	Software	BMB	Y
Provide Input Signal to Charge Switching Circuits	Software	BMB	Y
Provide Input Signal to Charge Switching Circuits	Hardware	Module	N
Control Charge Switching Elements 	Hardware	Module	Y
Provide Cell Under Voltage (CUV) Protection   	 	 	 
Sense Cell Voltages	Hardware	Module	Y
Read Cell Voltages	Software	BMB	Y
Sense Module Current	Hardware	BMB	Y
Read Module Current 	Software	BMB	Y
Implement CUV Protection Algorithm	Software	BMB	Y
Provide Input Signals to Discharge Switching Circuits	Software	BMB	N
Control Discharge Switching Elements	Hardware	Module	Y
Provide Over Current Discharge Protection (OCD)  	 	 	 
Sense Module Current	Hardware	Module	Y
Read Module Current 	Software	BMB	Y
Implement OCD Protection Algorithm	Software	BMB	Y
Provide Input Signals to Discharge Switching Circuits	Software	BMB	N
Control Discharge Switching Elements	Hardware	Module	Y
Provide Module Under Voltage Protection (MUV)  	 	 	 
Sense Module Voltage	Hardware	Module	Y
Read Module Voltage	Software	BMB	Y
Sense Module Current	Hardware	BMB	Y
Read Module Current 	Software	BMB	Y
Implement MUV Protection Algorithm	Software	BMB	Y
Implement MUV Protection 	Hardware	Module	Y
Provide Input Signal to Charge Switching Circuits	Hardware	Module	N
Provide Input Signals to Charge Switching Circuits	Software	BMB	N
Control Charge Switching Elements 	Hardware	Module	Y
Provide Over Temperature Charge Protection (OTC)  	 	 	 
Sense Cell Temperatures	Hardware	Module	Y
Read Cell Temperatures 	Software	BMB	Y
Sense Module Current	Hardware	BMB	Y
Read Module Current 	Software	BMB	Y
Implement AOT Protection	Hardware	Module	Y
Implement OTC Protection Algorithm	Software	BMB	Y
Provide Input Signal to Charge Switching Circuits	Software	BMB	N
Provide Input Signal to Charge Switching Circuits	Hardware	Module	N
Control Charge Switching Elements 	Hardware	Module	Y
Provide Over Temperature Discharge Protection (OTD)  	 	 	 
Sense Cell Temperatures	Hardware	Module	Y
Read Cell Temperatures 	Software	BMB	Y
Sense Module Current	Hardware	Module	Y
Read Module Current 	Software	BMB	Y
Implement AOT Protection	Hardware	Module	Y
Implement OTD Protection Algorithm	Software	BMB	Y
Provide Input Signal to Discharge Switching Circuits	Software	BMB	N
Provide Input Signals to Discharge Switching Circuits	Hardware	Module	N
Control Discharge Switching Elements	Hardware	Module	Y
Provide Module Over Voltage Charge Protection (MOV)	 	 	 
Sense Module Voltage	Hardware	Module	Y
Read Module Voltage 	Software	BMB	Y
Sense Battery Current	Hardware	BMB	Y
Read Battery Current 	Software	BMB	Y
Implement MOV Protection Algorithm	Software	BMB	Y
Provide Input Signal to Charge Switching Circuits	Software	BMB	N
Control Charge Switching Elements 	Hardware	Module	Y
Provide Short Circuit Discharge Protection (SCD)	 	 	 
Sense Battery Current	Hardware	BMB	Y
Read Battery Current 	Software	BMB	Y
Sense Module Current	Hardware	Module	Y
Read Module Current 	Software	BMB	Y
Implement SCD Protection	Hardware	Module	Y
Implement SCD Protection Algorithm	Software	BMB	Y
Provide Input Signals to Discharge Switching Circuits	Software	BMB	N
Provide Input Signals to Discharge Switching Circuits	Hardware	Module	N
Control Discharge Switching Elements	Hardware	Module	Y
Perform Thermal Management	 	 	 
Sense Cell Temperatures	Hardware	Module	Y
Read Cell Temperatures 	Software	BMB	Y
Sense Disable Heater Discrete Input Signal	Hardware	BMB	Y
Read Disable Heater Discrete Input Signal	Software	BMB	Y
Implement Thermal Management Algorithm	Software	BMB	Y
Provide Input Signals to Heater Switching Circuits 	Software	BMB	N
Implement Heater Over Temperature Protection	Hardware	Module	Y
Provide Input Signals to Heater Switching Circuits 	Hardware	Module	N
Control Heater Switching Elements	Hardware	Module	Y
Generate Heat for Cells	Hardware	Module	Y
Perform Built-In Tests	 	 	 
Sense Module Voltage	Hardware	Module 	Y
Read Module Voltage 	Software	BMB	Y
Sense Module Current	Hardware	Module	Y
Read Module Current 	Software	BMB	Y
Sense Cell Voltages	Hardware	Module	Y
Read Cell Voltages 	Software	BMB	Y
Implement Switch Check Algorithm	Software	BMB	Y
Implement Internal Communication Check Algorithm	Software	BMB	Y
Prepare Battery Status Data	Software	BMB	Y
Provide ARINC429 Communication	 	 	 
Provide Input Signals to ARINC429 Circuit	Software	BMB	Y
Convert Logic Level Signals to ARINC429 Level	Hardware	BMB	Y
Provide ARINC429 Signals to Communication Connector	Hardware	BMB	N
Provide State of Health (SOH) Estimation	 	 	 
Provide SOC Estimation to SOH Estimation Algorithm	Software	BMB	Y
Implement SOH Estimation Algorithm	Software	BMB	Y
Provide Input Signals to ARINC429 Circuit	Software	BMB	N
Convert Logic Level Signals to ARINC429 Level	Hardware	BMB	Y
Provide ARINC429 Signals to Communication Connector	Hardware	BMB	N
Provide State of Charge (SOC) Estimation	 	 	 
Sense Cell Temperatures	Hardware	Module	Y
Sense Module Current	Hardware	Module	Y
Sense Cell Voltages	Hardware	Module	Y
Read Cell Temperatures 	Software	BMB	Y
Read Module Current 	Software	BMB	Y
Read Cell Voltages 	Software	BMB	Y
Implement SOC Estimation Algorithm	Software	BMB	Y
Provide Input Signals to ARINC429 Circuit	Software	BMB	N
Convert Logic Level Signals to ARINC429 Level	Hardware	BMB	Y
Provide ARINC429 Signals to Communication Connector	Hardware	BMB	N
Provide Input Signal to SOC Analogue Circuit	Software	BMB	N
Provide SOC Analogue Signals to Communication Connector 	Hardware	BMB	N
Provide Battery Temperature Analog Output Signal	 	 	 
Sense Temperature	Hardware	-	N
Provide Temperature Analogue Data to Communication Connector 	Hardware	BMB	N
Provide Heating Status Discrete Output Signal	 	 	 
Prepare Battery Status Data	Software	BMB	Y
Provide Input Signal to Discrete Heating Circuit	Software	BMB	N
Provide Heating Status Discrete Output Signal to Communication Connector	Hardware	BMB	N
Read Disable Battery Discrete Input Signal	 	 	 
Sense Disable Battery Discrete Input Signal	Hardware	BMB	Y
Read Disable Battery Discrete Input Signal	Software	BMB	Y
Provide Input Signals to Discharge Switching Circuits	Software	BMB	N
Control Discharge Switching Elements	Hardware	Module	Y
Provide Input Signal to Charge Switching Circuits	Software	BMB	N
Control Charge Switching Elements 	Hardware	Module	Y
Read Disable Heater Discrete Input Signal	 	 	 
Sense Disable Heater Discrete Input Signal	Hardware	BMB	Y
Read Disable Heater Discrete Input Signal	Software	BMB	Y
Provide Input Signal to Heater Switching Circuits	Software	BMB	N
Control Heater Switching Elements	Hardware	Module	Y
Provide Data Logging	 	 	 
Prepare Battery Status Data	Software	BMB	Y
Provide Logging Data to Memory	Software	BMB	Y
Indicate Battery Status 	 	 	 
Sense Indicator Button 	Hardware	BMB	Y
Read Indicator Button 	Software	BMB	Y
Implement Output On/Off Control Algorithm	Software	BMB	Y
Implement SOC Estimation Algorithm	Software	BMB	Y
Prepare Battery Status Data	Software	BMB	Y
Provide Input Signals to Battery Status Indicator Circuit	Software	BMB	N
Control Battery Status Indicator	Hardware	BMB	Y
Provide Fault Warning	 	 	 
Prepare Battery Status Data	Software	BMB	Y
Provide Fault Signal in Logic Level to Discrete Circuit	Software	BMB	N
Provide Fault Warning Signal to Communication Connector	Hardware	BMB	N
Provide Service Warning	 	 	 
Prepare Battery Status Data	Software	BMB	Y
Provide Fault Signal in Logic Level to Discrete Circuit	Software	BMB	N
Provide Service Warning Signal to Communication Connector	Hardware	BMB	N
Limit Charge Current	 	 	 
Sense Module Current	Hardware	Module	Y
Read Module Current 	Software	BMB	Y
Implement Current Limiting Algorithm	Software	BMB	Y
Provide Input Signal to Charge Switching Circuits	Software	BMB	N
Control Charge Switching Elements 	Hardware	Module	Y
Provide Low Capacity Discrete Output Signal	 	 	 
Check SOC of Battery	Software	BMB	Y
Provide Input Signal to Discrete Low Capacity Circuit	Software	BMB	N
Provide Low Capacity Discrete Output Signal to Communication Connector	Hardware	BMB	N
Select Battery Mode 	 	 	 
Sense Disable Battery Discrete Input Signal	Hardware	BMB	Y
Read Disable Battery Discrete Input Signal	Software	BMB	Y
Sense Module Current	Hardware	Module	Y
Read Module Current 	Software	BMB	Y
Implement Mode Selection Algorithm	Software	BMB	Y
Provide Input Signal to COTS Power Devices	Software	BMB	N
Control COTS Power Devices	Hardware	Module	Y
Provide Input Signal to Charge Switching Circuits	Software	BMB	N
Control Charge Switching Elements 	Hardware	Module	Y
Provide Input Signals to Discharge Switching Circuits	Software	BMB	N
Control Discharge Switching Elements	Hardware	Module	Y
Provide Engine Start Status Discrete Output Signal 	 	 	 
Prepare Battery Status Data	Software	BMB	Y
Provide Input Signal to Discrete Engine Start Circuit	Software	BMB	N
Provide Engine Start Status Discrete Output Signal to Communication Connector	Hardware	BMB	N
The details of the functions are in the BL-SD-001-0003 System Description Document.

 
5.1.2	Hardware and Software Interfaces
5.1.2.1	External Interfaces
The battery will have two different external electrical connections. First are employed for power delivery during charging and discharging operations that is connected to platform of electrical power system. The  second connection serves as a communication interface, supporting ARINC429, discrete, and analog communications between the aircraft (A/C) and the battery for data transfer purposes.
Detailed of External Interfaces are described in BL-IC-001-0003 Interfrance Control Document.
5.1.2.2	Internal Interfaces
The software must have various interfaces to perform the functions allocated to it. 
Analog Interfaces:
Analog output
o	Battery SOC level
Digital interfaces:
Digital inputs:
o	Modul Detected: GPIO input signal that detects that the modules are active.
o	Load Detected: GPIO input signal to detect the presence of load at the battery output.
Digital Outputs:
o	Switch off: GPIO signal to directly turn the battery output on and off.
o	Module Enable: GPIO signal to enable modules.
Discrete inputs:
o	Disable Battery: incoming signal to turn the battery output on/off.
o	Disable Heater: incoming signal to set the heater feature on/off.
o	Check SOC Button: button signal to turn indicator on.
Discrete outputs:
o	ACTIVE: indicates the state of battery output (Active discrete signal is provided by software in order to turn on the Active LED of the indicator).
o	HEATER: indicates the state of heater.
o	FAULT: indicates if there is a fault in the battery.
o	SERVICE: indicates that the battery needs service.
SPI
o	Flash integration is required to record error conditions.
o	Real-time clock (RTC) will be used for time stamped logging and SOC algorithm.
I2C
o	The BMB's main processor (MCU) uses one of its I2C channels to communicate with the Monitor Board and Control Board. This allows the BMB to send commands and receive data from the Monitor Board for control, monitoring, and protection purposes. It monitors battery current, module current, heater current, cell temperatures, switch temperatures, limiter current, battery voltage, module voltage.
These communication channels allow the software to manage and monitor the battery's operation effectively.
5.1.3	Executive Summary
5.1.3.1	Processor Used
Texas Instruments (TI) TMS320F28377S (See Figure 3:TMS320F28377S Functional Block Diagram) is used to be platform where the DO-178C applicable battery software run on. An external clock will be used to provide clocking signal for CPU and Timers. Software Load Integrity will be ensured by CRC32 (Ethernet). Primary Features are listed below.
•	Internal Memory 1024 Kbyte flash, 164 Kbyte RAM 
•	Package: 100 pins (256 mm² 16 x 16)
•	16 Analog Input
•	32–bit CPU
•	Floating-Point Unit (FPU)
•	ECC protected memory
•	External Clock
•	UART, SPI, I2C, DAC, ADC Channels

 
Figure 3:TMS320F28377S Functional Block Diagram
5.1.3.2	FPGA Used
There is no FPGA used in this system
5.1.4	System Failure Conditions
All system functions and failure conditions are described in the RP-PSSA-001-0003 TLUH Preliminary System Safety Assessment.
5.1.5	High-Level Hardware Functions and Contribution to Potential Failures 
High level hardware functions are given in Table 7. Only functions with branch level DAL A and DAL B are added to the table. The loss of function is explained with a short example.
Table 7 High-Level Hardware Functions and Contribution to Potential Failures
No	Potential Failure  of Battery Functions	DAL
1	Loss of provide input signal to discharge siwitching. The battery cannot be discharged. It cannot supply the 28VDC bus.	B
2	Loss of provide input signal to charge switching. The battery cannot be charged. 	B
3	Loss of COV protections 	B
4	Loss of AOT protections 	B
5	Loss of MUV protections	B
6	Loss of SCD protections 	B
7	Loss of battery disable discrete. The battery cannot be activated or deactivated by the user.	B

 
6	HARDWARE OVERVIEW
This section describes the hardware functions, hardware items and architecture of lithium ion battery.
6.1	Hardware Architecture
 The lithium ion battery is comprised of 3 modules, each containing a control board, a monitor board, cells, a heater, and thermal sensors. Each module, consisting of four parallel-connected cells, provides 10Ah of capacity. The entire battery consists of 6 such modules and offers a total capacity of 30Ah. 30Ah capacity is valid for BOL, the capacity may decrease over time as the battery ages. It will provide energy to the user up to the EOL capacity value of the battery. Details are stated in the BL-SD-001-0003 System Description Document.The modules are connected in parallel to achieve the desired capacity. Additionally, each module utilizes eight series-connected cells to meet the normal emergency operating voltage range specified by MIL-STD-704F. This configuration uses a total of 96 cells.
 The modular design offers redundancy and enhances safety. Each module incorporates a control board, a monitor board, cells, thermistors for cell temperature measurement, and a heater. The modules are designed to deliver 10Ah capacity at a voltage of 28V and are connected in series-parallel configuration. Figure 4 illustrates the preliminary design architecture of the 28VDC battery system.
BMB provides battery management, calculates battery charge status (SOC), checks battery health status (SOH), processes discrete input and output signals and acts accordingly, reports battery fault and service status, records battery fault data, service, extreme conditions and configuration of the battery in software. 
The monitor board reads the data (temperature, current, voltage) required for battery management and sends the read values as analogue signals to the analogue protection circuit and to the BMB using I2C communication. The data processed on the BMB card and the signal output of the analogue protection circuit are transferred to the charge-discharge logic circuit of the monitor card. The charge-discharge logic circuit will be designed considering safety criteria. The output signal of the logic circuit will be transferred to the control card and will control the switching elements on the control card. In addition, the monitor card will perform the cell balancing process to correct the imbalance between the cells. Figure 2 clarifies the modular design concept for 28 VDC battery.


       Figure 4 Pre-design architecture of lithium ion battery
The control board consists of switching elements. Switching elements on the control board are opened or closed according to the commands from the monitor board. These switching elements cut the battery charge input or battery discharge output according to the protection mode of the battery. Since the battery charge-discharge process consists of a single power connector, the battery cannot be charged and discharged at the same time. The battery has a current limiting circuit to prevent giving a large amount of charging current to the cells during charging and to reduce the voltage drop in the electrical power system platform line. The battery has no need separate charger. The control board also has a heater switching contains the elements.
In addition, each module has a heater in order to increase the temperature of the cells in low temperature conditions of the battery and to protect the cell structure and health.
When the battery temperature drops and in case of discharge, the discrete heater enable signal comes from the user or when the low temperature value determined by the software is reached, BMB decides whether to turn on or off the heater by sending a signal to the control board to the heater control switch circuit.
There are two additional RTD temperature sensors in the battery pack. The RTD sensor is completely independent of the hardware and software team. PT100 sensors will be used as RTD sensors due to their more stable and high temperature ranges.
To deliver required power, battery cells needs to be connected in series and parallel. However, high robustness and reliability can be achieved by modular configuration that consists of several modules backing up each other to sustain safety critical missions. 
6.1.1	BMB
The BMB board is independent of the modules and manages the power control of the battery and the external data interface. The software running on the BMB microcontroller provides instructions to the Monitor cards and through it to the Control panels to control the battery, using the cell and sensor data transmitted to it by the Monitor cards. The BMB generates battery status and data, which is provided to the aircraft via the 19-pin communications connector for cockpit monitoring. Data is provided in serial (ARINC 429), discrete and analog formats. The battery does not contain airborne electronics or complex hardware known as AEH. BMB is a circuit board that contains the COTS ICs, the necessary supply circuits for these ICs, and the MCU on which the software will run. It communicates with BMB modules via isolated I2C, manages and evaluates incoming and outgoing input-output signals from the communication connector. It checks the error, service, health and charge status of the battery and transmits it to the communication connector. The software running on the BMB provides SCD protection for the battery pack and MOV, CUV, COV, MUV, OTC, OTD protection for the modules. BMB also provides the logic that drives the built-in visual status indicator on the outside of the case. Additionally, BMB operates a built-in visual status indicator on the outside of the chassis that displays fault conditions, service statuses, and the SOC status of the battery. The BMB functional block diagram is shown in Figure 5. The BMB board also measures battery current via the current sensing board. The current sensing board consists of only a shunt resistor and connector.

6.1.1.1	Microcontroller Unit
Single core COTS MCU will be used in the BMB. There will be no micro-code in the MCU. MCU executes its software functions by using the data it receives.
6.1.1.2	BMB Power Supply
The BMB will receive its power directly from modules connected in parallel. Thus, even if any module is disabled, the BMB supply is not interrupted. The BMB power supply will produce ±7.5VDC isolation, three +5VDC isolation, +6VDC isolation for the COTS integrated circuits on the BMB, and +3.3VDC isolation and +1.2VDC voltage values required for the MCU.
6.1.1.3	Input Line filter And Hold-Up
In order to ensure EMC compatibility before the ICs on the BMB board are fed, an input filter circuit will be added to filter the noise coming from and coming from the battery before the BMB power supply hardware. Filter hardware will consist of passive circuit elements. In addition, a holdup capacitor circuit will be added so that the instantaneous voltage drop in the module voltage does not affect the MCU and communication line on the BMB in case of high current draw from the battery. The holdup circuit will provide the power to the BMB when high current is drawn from the battery. The hold-up circuit will consist of passive circuit elements.
6.1.1.4	ARINC429 Line Drive
The ARINC 429 signal from the MCU will convert the signal to ±5 volts through the ARINC 429 Line Driver in isolation. The signals coming out of the ARINC 429 Line driver will be filtered and transferred to the communication connector with current limiting. The circuit will contain COTS simple IC. Details are described in the BL-SD-001-0006 system description document.
6.1.1.5	Isolated Discrete Input
It will filter the input signals coming from the communication connector and transfer them to the MCU in isolation. These signals will be discrete battery disable and discrete heater enable signals. Simple COTS IC will be used.
6.1.1.6	Isolated Discrete Output
It will filter the isolated signals from the MCU and transfer them to the communication connector. These signals will be Discrete Fault and discrete Service status signals. Simple COTS IC will be used.
6.1.1.7	Data Logging
It will record the error and service conditions of the battery, how many times it went to which error. Data logging circuit will include RTC and Flash memory ICs as COTS. The data to be recorded and how it will be recorded are explained in detail in the PL-PSA-001-0001 Plan for Software Aspect of Certification document.
6.1.1.8	Communication Isolation
Communication between BMB and Modules will be isolated I2C. COTS simple IC will be used for isolation of communication.
6.1.1.9	Analogue SOC
It will convert the logic level SOC value from the MCU to a voltage range of 0 VDC to 5VDC. The converted SOC voltage value will be filtered and transmitted to the communication connector. Simple COTS IC will be used for Analogue SOC.
6.1.1.10	Pack Monitoring
It detects the charge-discharge current of the battery pack by converting the voltage value taken from the battery's main current sensor into current. It will digitally transmit the detected current data to the MCU. Also it will be used to detect when a charger is connected to the battery power connector. Provides precise current reading for SOC calculation. Simple COTS IC will be used.
6.1.1.11	Led Driver 
According to the battery status and SOC data received from the MCU, the battery will provide voltage signals to the status indicator. In addition, it will detect the status of the SOC check button on the battery status indicator and transmit it to the MCU. Simple COTS IC will be used.
6.1.1.12	Module Enable 
In case the battery goes into sleep mode, the module enable signal from the MCU cuts the energy of the Cots ICs (except the module monitor circuits) of the modules. When the battery is in active mode, the enable signal is sent back to the modules by the MCU.
6.1.2	Modules
Each module will contain control board, monitor board, cell temperature sensors, cells, heater. Each module will be identical to each other. The specs of the module are given in Table 8.
Table 8 Each module cell configuration details
Parameter	Characteristic
Module Nominal Voltage	26.4 VDC
Module Nominal Capacity	10Ah
Module Cell Configuration	8 Series 4 Parallel Cells
Since the design is a modular structure, each module will protect at its own level. Pack-level protection will be provided when all modules act according to their protection status.
6.1.2.1	Monitor Board
The Monitor board contains the logic for collecting cell parameters and reporting them to the Battery Management Board (BMB). It takes decisions from the BMB and sends information to the Control board to enable charging and discharging, limit charging current, disable heater control. It also sends information to BMB about the status of analogue protections. The monitor board will consist of simple COTS ICs and the hardware to feed these ICs. The block diagram of the monitor board is shown in Figure 6.

 
6.1.2.1.1	Cell Balance
LFP battery cells may vary depending on their chemical structure, capacity, ambient temperature, chemical processing, storage and use. This can happen over time, no matter how equivalent we choose the cells. Cell balancing will be done in order to use the possible energy and filling amounts of the cells as well as possible. Passive balancing will be used in the battery. The cell balancing algorithm will be processed in the module monitoring circuit and will control the passive circuit elements on the cell balancing circuit. Cell balancing is done by controlling the passive elements. The cell balance circuit will contain simple passive elements.
6.1.2.1.2	First Analogue Protection
Analogue protections for redundant structure have been added to the necessary system level functions in accordance with the DAL levels obtained according to the results of the FTA security analysis of the system level functions. 
Analogue protections are:
•	Analogue COV protection.
•	AOT protection.
•	Analogue heater over temperature protection.
It detects cell voltages and cell temperatures in each module. It produces a voltage output when cell voltage or cell temperatures go outside specified threshold levels. Analogue protection is provided by transferring these voltage outputs to the heater control circuit, or charge logic circuit, or discharge logic circuit.
In addition, the first analogue protection circuit provides analogue protection for analogue heater overheating according to the signal coming from the Heater control circuit from the control boards in each module.
All analogue protection circuit will use COTS simple IC. These IC's just compered threshold value with instantaneous sensor values.
 
6.1.2.1.3	Charge Logic
It is the hardware that will control how the charge acceptance process will decide according to the input signals coming from the hardware and software. The charge logic control circuit will consist entirely of simple COTS logic gate ICs.
6.1.2.1.4	Discharge Logic
It is the hardware that will control how the discharge acceptance process will decide according to the input signals coming from the hardware and software. The discharge logic control circuit will consist entirely of simple COTS logic gate ICs.
6.1.2.1.5	Module Monitoring 
The monitor board will detect the sensor and cell data on the battery and transmit them to the MCU. For monitor operation, it will detect the voltage of each cell in the modules and transmit it to the MCU via I2C communication. It will not perform any operation other than monitor operation. There will be COTS IC for monitor operation.
6.1.2.1.6	Digital Control
The digital control circuit will consist of simple COTS integrated circuits only. The digital control circuit will be used to transfer the charge and discharge control switches according to the data from the MCU to the heater control switch with the signal from the software. Additionally, a digital control circuit will be used to return analogue protection states to the software.
6.1.2.1.7	Module Data Logging
It contains COTS and simple IC that will keep track of error states, error counts, maximum-minimum module data of each module. Detailed explanation is given in document PL-PSA-001-0001 Plan for Software Aspect of Certification.
6.1.2.1.8	Module Power Supply
In the monitor boards of each module, it is the supply circuit hardware that will power the COTS equipment in the module. The module power supply hardware will consist entirely of COTS simple converter ICs. It will consist of a dc to dc converter circuit that converts the module stack voltage to +3.3VDC to power the COTS ICs on the monitor board, and an isolated +12VDC and isolated +5VDC dc to dc converter circuit to the COTS ICs on the control board.
6.1.2.1.9	Analogue Control

The analogue control signals coming from the BMB will be transmitted to each module in isolation and the control board will directly control the charge and discharge switches and will be used for situations where the battery's power outputs need to be shut down quickly without any software delay. Analogue signal isolation hardware will consist of COTS and a simple isolation IC.
6.1.2.1.10	Predischarge
Predischarge hardware will include COTS switching elements. The hardware will perform two simple tasks. These tasks are:
• When a large amount of capacitive load is connected to the battery outputs, it will prevent the capacitive load from drawing instantaneous current.
• It will be used to detect when a load is connected to the battery power connector .
Predischarge will always be active. Predischarge will be disabled by the software when the battery enters discharge protection. Due to predischarge, there will be a current-limited voltage at the battery's power connector outputs when the battery is in standby mode and sleep mode.
6.1.2.1.11	Precharge
Precharge hardware will include COTS switching elements. The hardware will perform one simple tasks. These tasks are:
• When the battery enters a deep discharge state, it will be used to charge the modules with low current and remove it from the deep discharge state. When an external power source is connected to the battery in deep discharge state, the indicator will indicate that the battery is in service status. In case of deep discharge, the customer cannot charge the battery. 
6.1.2.1.12	Low Voltage Detect
The battery draws a very high current at the start of the engine. Due to the high current drawn, the cell voltages may drop to the 12VDC voltage specified in the MIL-STD 704F electrical starting condition. This instantaneously falling voltage may disrupt the electrical power of the BMB and cause the MCU and ARINC line to work incorrectly. The low voltage detect circuit cuts off the BMB supply from the modules at the moment of engine start to prevent all these from happening. BMB Supply is provided for a certain period of time thanks to the Hold-Up circuit on the BMB. When the electrical starting condition disappears, the modules supply power to the BMB again. Low voltage detect circuit includes simple COTS IC.
6.1.2.2	Control Board
The control board is the circuit board on which the switching elements, current readers and temperature reader COTS ICs are located. The control board is the circuit board on which the switching elements, current sensor and temperature sensor COTS integrated and temperature sensors are located. The control board communicates directly with the monitor board. According to the data coming from the monitor board, it controls the charging, discharging, charging current limitation of the module.


6.1.2.2.1	Charge Control
It is the hardware that will contain the switching elements that change position according to the signal coming from the Charge Logic circuit and the driver elements that will enable these switching elements to be controlled at appropriate voltage levels. COTS and simple ICs will be used. 
6.1.2.2.2	Charge Current Limiter
Charging cells with very high current is dangerous for cells. There will be a Charge Current Limiting circuit so that the cells to be used can be charged at the recommended charging currents. The charging current will be adjustable by software. The Charge Current Limiting circuit will consist of COTS simple switching elements and Cots simple DAC IC. It takes the current limit value from the MCU as voltage and limits the charging current according to the set value.
6.1.2.2.3	Discharge Control
It is the equipment that will contain the switching elements that change position according to the signal coming from the Discharge Logic circuit and the driver elements that will enable these switching elements to be controlled at appropriate voltage levels. COTS and simple ICs will be used.
6.1.2.2.4	Heater Control 
Since charging and discharging the battery at low temperatures will reduce the life of the cells and the usable capacity of the battery, it is the equipment that will control the optimum temperature for the cells during the charging and discharging of the battery at low temperatures.
The heater temperature is detected via the Monitor board. The detected heater temperature is transmitted to the control board in an analogue manner. Additionally, the detected heater temperature value is transmitted to the MCU as a digital signal via the heater control circuit. MCU applies the heater implement algorithm according to the status of the heater dictate signal it reads and the cell temperature conditions. These temperature ranges are detailed in the of PL-PSA-001-0001 Plan Software Aspect Certification. According to these situations, it provides the appropriate voltage signal to the analogue signal isolation circuit. Analogue isolation circuit provides appropriate voltage signal to the heater control circuit. The Heater Control circuit compares the signal it receives with the heater overheating signal coming from the first analogue protection at the logic gate. The output of the logic gates is converted to the appropriate voltage level and the heater control circuit changes the position of the heater control switches.
6.1.2.2.5	Second Analogue Protection 
According to the DAL levels obtained according to the FTA security analysis results of the system level functions, secondary level analogue protections for the redundant structure have been added to the required system level functions. Second Analogue Protection hardware consists of COTS simple ICs. Second Analogue Protection hardware includes the following protections:
•	SCD protection
•	MUV protection
The Second Analogue Protection hardware also includes module switch temperature and module limiter temperature sensors. The second analogue protection equipment will transmit the module current, heater current and limit current values it detects to the monitor board. The monitor board transmits data to the MCU. It also transmits module switch temperature and module limiter temperature sensor data as appropriate voltage output to the charge and discharge logic circuits. The second analogue protection equipment detects the module current, heater current, and limit circuit current values and transmits them to the MCU via the monitor board as a digital signal. In addition, the Module compares the current value with the predetermined SCD, MUV, threshold values and gives an error output voltage signal to the charge logic control and discharge logic control circuit.
6.1.2.3	Module Cells
Lithium FePO4 (LFP) chemistry allows high discharge current, provides energy reliably at high and low temperatures, is suitable for long-term operation and is safe when abnormal conditions occur. LFP is rated as the safest among cathode li-ion batteries because it has a low temperature rise when thermal runaway occurs and the probability of thermal runaway propagation is low.
It was chosen because it is suitable for the minimum drop voltage of the battery at the time of electrical start of the selected cell and for operation in the desired temperature ranges.
6.1.2.4	Module Heater
In cases where high current needs to be drawn from the battery, for example when starting the engine, the battery will need to show its best performance at optimum temperature. In order for the battery to provide optimum performance at low temperatures, to ensure that the amount of energy the cells can provide at low temperatures does not decrease, and to prevent the cell from aging faster, the cells must be heated to the optimum operating temperature. A heater will be used to heat the cells. The heater is a special production and each module will contain a heater within itself. The heater will contact as many cells as possible in the module. The required power supply for the heater can be provided from each module cell or by supplying energy to the battery from outside.
6.1.2.5	Cell Temperature Sensors
NTC temperature sensors will be used to detect the temperature of the module cells. Each module 2 temperature sensors will detect the temperature of the cells and transmit the sensor value to the monitor board.
6.1.3	Battery Status Indicator
Battery status indicator will consist of LED lights showing error, service, active and SOC value in 20 percent slices and SOC Check whole. It will change the status of LED lights on it according to the signals coming from the LED driver circuit on the BMB. The SOC check button transmits the status to the Led driver circuit. The battery status indicator is custom made and does not contain any COTS IC. Details are described in the BL-SD-001-0006 system description document.
6.1.4	Analogue RTD 
PT100 temperature sensors will be used as RTD. PT100 was preferred because it shows as linear variable value as possible in high and low temperature ranges. The analogue RTD temperature sensor is hardware independent. The sensor transfers the value directly to the communication connector via the BMB.
6.2	Architecture Mitigation
Architectural mitigation refers to changes and practices in the design and architecture of an electronic hardware system to increase resilience to errors and failures. Techniques such as FMEA (Failure Modes and Effects Analysis) and FTA (Fault Tree Analysis) are used to analyze possible failure modes and failure scenarios. As a result of the analysis, critical errors and malfunctions that affect the security of the system are determined. Architectural changes and additional security mechanisms identified in the mitigation strategy are applied to the system design and architecture. The impact of the mitigation on the performance and functionality of the system is evaluated. The effectiveness of the reduction is verified and proven by tests and analysis. The mitigation process is shown to meet the security requirements of the system. The methods to be used to reduce architecture in the DO-254 standard are:
Pluralism: Increasing the fault tolerance of the system by using more than one independent component. Critical functions in each module will be designed to increase fail tolerance for the same protection function as independent components.
Rollback and Recovery: In order to return the system to a safe state and recover in case of failure, the modular structure in the 28V battery will protect itself and exit protection independently of each other.
Safe Limiting: Limits are set to prevent erroneous operations from affecting critical functions of the system. The boundaries of each module will be determined independently.
Architectural reduction is an important element to design and develop an electronic hardware system that complies with the DO-254 standard. The mitigation strategy is carefully developed taking into account the security requirements and risk tolerance of the system. Considering system safety requirements and risk tolerances, the 28V Battery has two failure paths that are considered DAL B. These are thermal runaway and termination of the battery discharge function. Architectural mitigations for these fault paths are shown in RP-PSSA-001-0003.
6.3	Hardware Fault Management
6.3.1	Fault Tolerance
One of the most important functions of the battery is discharge. Precautions have been taken in the design to increase the fault tolerance of this function. Even if the MCU is disabled for any reason, the battery will continue to discharge by operating the discharge switches. When the battery does not receive any data about cell voltages and cell temperatures from the modules at the time of disharging, it does not enter the discharge software protection. It will continue to discharge due to hardware protection.
Since the battery has a modular structure, even if any module loses its full functional function, there will be a loss in battery capacity, but all functions will be fulfilled.
Each module has a mechanical cell fuse for each cell. In this way, a short circuit of one cell will not consume the capacity of other cells in parallel. In this way, the battery will continue to be active in the system with less capacity.
6.3.2	Fail Safe
The most dangerous failure of the battery for the system is thermal runaway. Various precautions have been taken to prevent this situation and to protect the health of the cells, which are the most important elements of the battery. The hardware, together with the software, protects the battery from malfunctions such as COV, CUV, OTD, MOV, MUV, SCD.
Each module has mechanical fuse in its cells. Even if the battery completely fails in software and hardware, it protects itself without entering the thermal runaway with the cell fuses. Additionally, precautions will be taken to protect the battery case from thermal runaway.
In addition, the 2 RTD sensors built into the battery transmit the battery temperature information separately from all other items.
 
6.4	Hardware Functions
All hardware functions are described in Table 9.
Table 9  Hardware Functions
Hardware Functions	Explanations
Provide Input Signals to Discharge Switching Circuits	It generates a voltage signal according to the signals it receives from the discharge logic circuit input. The generated signal is transmitted to the discharge switch circuit on the control board. Discharge switch circuit provides the appropriate voltage to the discharge switching elements to control the discharge switch elements.
Control Discharge Switching Elements	It opens or closes the discharge switches according to the voltage signal from the discharge control circuit. The battery powering the system is provided by the control of the discharge switching elements.
Provide Input Signal to Charge Switching Circuits	It generates a voltage signal according to the signals it receives from the charge logic circuit input. The generated signal is transmitted to the charge switch circuit on the control board. The charge switch circuit provides the appropriate voltage to the charge switch elements (charge switch / limiter) to control the charge switch elements.
Control Charge Switching Elements 	It opens or closes the charge switches (charge switch / limiter) according to the voltage signal coming from the charge control circuit. Charge acceptance process is provided by the control of switching elements.
Sense Cell Voltages	The monitor circuit on the monitor board detects the voltages of each cell and transmits them to the MCU.
Implement COV Protection	The monitoring circuit in the module generates an error signal when any module cell detects a cell voltage above the analogue COV threshold. The generated error signal is transmitted to the charging logic circuit of the module.
Sense Modul Current	The second analogue protection circuit and monitor circuit in the modules detect the current of each module and transmit it to the MCU via the Monitor Board.
Sense Cell Temperatures	The monitor circuit detects the state of the cell temperatures in each module through the temperature sensors in the module. The temperature sensor data of each module is transmitted to the MCU.
Implement AOT Protection	The first analogue protection circuit in the modules generates an error signal when it detects a temperature above the analogue over temperature (AOT) threshold. The error signal is transmitted to the discharge and charge logic circuit. Error status is transmitted to the MCU via the monitor board.
Implement MUV Protection	Each module produces an output signal when it detects a voltage below the MUV threshold. The produced output signal is transferred to the charge and discharge logic control circuits. After the logical test in the logic, if necessary, it cuts off the module discharging by pulling the module's discharging switches to the off state.
Sense Modul Voltage	The secondary analogue protection circuit in each module detects the total module voltage of the relevant module and transmits it to the MCU.
Implement SCD Protection	The second analogue protection circuit in the modules generates a fault signal when it detects a module discharge current above the analogue SCD threshold. The error signal is transmitted to the charge and discharge logic circuit. The error status is transmitted to the MCU via the monitor board. In the SCD state, the charge and discharge switches are open together.
Sense Disable Heater Discrete Input Signal	Isolation Discrete input circuit detects the sense disable heater signal coming from the communication connector, filters it, and transmits it to the MCU in isolation.
Implement Heater Over Temperature Protection	The first analogue protection circuit in the modules generates an error signal when the heater in each module detects a temperature above the overheating threshold. The generated error signal is transmitted to the heater control circuit. In addition, the heater status is transmitted to the MCU by measuring the heater current.
Provide Input Signals to Heater Switching Circuits 	In each module, an error output is produced after the signals coming to the logic control circuit are evaluated through logic gates. This generated error signal is converted to the voltage levels required to control the heater switching elements. The converted voltage level is transmitted to the heater switching elements.
Control Heater Switching Elements	The position of the heater switches changes according to the signals coming to the heater switching elements. The heater switching elements turn on or off according to the thermal management conditions of the battery. Thus, the active or passive state of the heaters in the modules is changed.
Generate Heat for Cells	The modules must generate heat for the cells in the low temperature condition. Heater control circuit controls the heater status. The heater converts electrical energy into heat energy with external electrical power from the module cells or from the outside.
Convert Logic Level Signals to ARINC429 Level	The logic signal between 0VDC and 3.3VDC voltage level from the MCU is transmitted to the ARINC429 Line Driver circuit. The ARINC429 Line Driver circuit converts the signal from -5VDC to +5Vdc.
Provide ARINC429 Signals to Communication Connector	Signals at +5VDC and -5VDC voltage levels coming from the ARINC 429 Line Driver circuit are transmitted to the communication connector.
Provide SOC Analogue Signals to Communication Connector 	The signals at the voltage levels of 0VDC and +5VDC coming from the analogue SOC circuit are transmitted to the communication connector by filtering.
Sense Temperature	Hardware independent RTD sensors are located at certain points of the battery pack. RTD sensor line is connected to communication connector on BMB.
Provide Temperature Analogue Data to Communication Connector 	The RTD temperature sensor value coming to the BMB is transmitted directly to the communication connector.
Provide Heating Status Discrete Output Signal to Communication Connector	It isolates the Heating status signal coming from the MCU and transmits it to the communication connector.
Sense Disable Battery Discrete Input Signal	The battery discrete disable signal from the communication connector is transmitted to the isolation discrete input circuit. The circuit detects this signal and transmits it to the MCU in isolation.
Sense Indicator Button 	The LED driver circuit on the BMB detects whether the indicator button is pressed and transmits it to the MCU.
Control Battery Status Indicator	Signals including battery error, service, soc, battery active and heater conditions coming to the led driver circuit are converted to appropriate voltage levels in the led driver circuit and control the leds on the battery status indicator.
Control COTS Power Devices	As the output of the MCU mode selection algorithm, the battery will work in two modes as active and sleep mode. When the battery works in sleep mode, MCU generates signal outputs and sends disable signal to Cots Devices on Modules. Thus, its internal consumption is minimized when the battery is not used and in storage situations. If the battery is active, the MCU sends an enable signal to the same COTS devices from the same signal lines, ensuring the active operation of the COTS products.
Provide Fault Warning Signal to Communication Connector	It isolates the Fault warning signal coming from the MCU and transmits it to the communication connector.
Provide Service Warning Signal to Communication Connector	It isolates the Service warning signal coming from the MCU and transmits it to the communication connector.
Provide Low Capacity Discrete Output Signal to Communication Connector	It isolates the Low capacity signal coming from the MCU and transmits it to the communication connector.
Provide Engine Start Status Discrete Output Signal to Communication Connector	It isolates the Engine start status signal coming from the MCU and transmits it to the communication connector.
Sense Battery Current	It detects the charging and discharging currents of the battery on pack monitoring circuit and transmits them to the MCU.

Sense Battery Voltage	It detects the total voltage level of the battery and transmits it to the MCU. Total voltage; Active is equal to the parallel connected module voltages that have not closed the charge/discharge outputs due to any protection.
 
6.5	Hardware Items
All COTS ICs to be used in hardware design are given in Table 10. DAL levels of critical components that will emerge as a result of FTA analysis will be determined.
Table 10 Hardware COTS Items
Device ID	LMR36506RFRPER
Manufacturer	Texas Instruments
Circuit Board	Monitor Board
Class (Simple or Complex)	Simple
Proofs of simplicity (if simple)	This COTS has a simple block diagram. Its function on the board is voltage regulation.
Hardware Function Allocated to device	It produces the necessary voltage for the supply of the switching elements on the control board and the supply of the COTS devices on the monitor board.
COTS lifecycle data	New Product. The datasheet was published in 2023.
SEU Susceptibility	When the block diagram of the product is examined, there is no SRAM or memory type structure that can be affected by soft error. SEU Sensitivity is low.
Errata Sheet Analysis or Quality, reliability & packaging data 	There is no errata sheet. IC includes Quality, reliability and packaging data analysis by manufacturer
Operational environmental conditions	Operating Junction Temperature -40 +150 °C.
 	 
Device ID	TPS62420QDRCRQ1
Manufacturer	Texas Instruments
Circuit Board	BMB
Class (Simple or Complex)	Simple
Proofs of simplicity (if simple)	This COTS has a simple block diagram. Its function on the board is voltage regulation.
Hardware Function Allocated to device	It generates the necessary voltage to power the logic elements on the monitor board.
COTS lifecycle data	COTS Status is active. It recommended for new designs
SEU Susceptibility	When the block diagram of the product is examined, there is no SRAM or memory type structure that can be affected by soft error. SEU Sensitivity is low.
Errata Sheet Analysis or Quality, reliability & packaging data	There is no errata sheet. IC includes Quality, reliability and packaging data analysis by manufacturer.
Operational environmental conditions	Operating Junction Temperature -40 +150 °C.
 	Operating ambient temperature -40 +85 °C
Device ID	TMS320F28377SPZPQ
Manufacturer	Texas Instruments
Circuit Board	BMB
Class (Simple or Complex)	COTS microcontroller with complex peripheral interfaces, Complex
Proofs of simplicity (if simple)	Minimal Peripheral Utilization: The MCU is employed in a straightforward application where only a few basic peripherals are utilized.
Low Processing Demands: The application places minimal demands on processing power and doesn't involve complex algorithms or multitasking.
Limited Software Complexity: Simple usage patterns entail writing straightforward code without the necessity for complex software libraries or real-time operating systems (RTOS).
Low Resource Utilization: The MCU does not fully leverage all of its available resources (e.g., unused hardware timers, unused communication interfaces), which contributes to its perceived simplicity.
Hardware Function Allocated to device	-
COTS lifecycle data	COTS Status is active. It recommended for new designs
SEU Susceptibility	Medium
Errata Sheet Analysis or Quality, reliability & packaging data	“TMS320F2837xS Real-Time MCUs Silicon Errata Silicon Revisions C, B” document has been reviewed. It was seen that the modules used would not be affected. Also an analysis report is planned for this document. This report will show that errors in errata do not affect the product.

Operational environmental conditions	Operating Junction Temperature -40 +125 °C.
 	 
Device ID	LM5180QNGURQ1
Manufacturer	Texas Instruments
Circuit Board	BMB, Monitor
Class (Simple or Complex)	Simple
Proofs of simplicity (if simple)	This COTS has a simple block diagram. Its function on the board is voltage regulation.
Hardware Function Allocated to device	It is used to generate the necessary voltage for the MCU and communication.
COTS lifecycle data	COTS Status is active. It recommended for new designs.
SEU Susceptibility	Medium. It has a Safety Manual. In this manual, failure rate estimation, qualitative and quantitative failure analysis are available.
Errata Sheet Analysis or Quality, reliability & packaging data	There is no errata sheet. IC includes Quality, reliability and packaging data analysis by manufacturer.
Operational environmental conditions	Operating Temperature -40 +150°C.
 	 
Device ID	BQ7695202PFBR
Manufacturer	Texas Instruments
Circuit Board	Monitor Board
Class (Simple or Complex)	Simple
Proofs of simplicity (if simple)	•	According to the document’s AC 20-152A explains in Section 6.3 and AC-00-72 explains with examples in Section 3.2.1, the IC is simple.
•	According to AC 20-152A Simplicity and Number of Functions: BQ76952 has relatively simple functions such as voltage and current measurement of the battery, temperature monitoring, cell balancing and protection. The number of functions is also limited. The number of functions is also limited. It will be used only to monitor cell voltages in each module.
•	Number and Simplicity of Interfaces: The BQ76952 IC has a limited number and relatively simple interfaces such as I2C, SPI (planned) and a few discrete I/Os.
•	 Data/signal Processing or Transfer Simplicity: Using an integrated analog-to-digital converter (ADC) and internal computing units, the BQ76952 converts the analog signals it receives into digital signals and runs battery management algorithms. These operations are simpler compared to complex microprocessor applications.
•	 Independence of Functions/Blocks/Stages: The internal blocks of the BQ76952 operate independently of each other. This independence simplifies testing and analysis processes.
•	Synchronous Design: BQ76952 has a synchronous design. This eliminates the need for complex timing mechanisms and simplifies the design.
•	Number of Independent Clock: BQ76952 operates with a single master clock signal. This simplifies the design.
•	State Machines: The BQ76952 has a relatively small number of state machines, and the number of states and state transitions in each state machine are limited. This reduces complexity.

Hardware Function Allocated to device	It is used to measure cell voltage, to measure battery current, to measure cell temperatures and to analogue control the control of switching elements according to pre-configured threshold parameter values.
COTS lifecycle data	COTS Status is active. It recommended for new designs
SEU Susceptibility	Medium.
Errata Sheet Analysis or Quality, reliability & packaging data	There is no errata sheet. IC includes Quality, reliability and packaging data analysis by manufacturer.
Operational environmental conditions	Operating Temperature -40 +85 °C.
 	 
Device ID	LT8301IS5#WTRMPBF
Manufacturer	Analog Devices
Circuit Board	BMB
Class (Simple or Complex)	Simple
Proofs of simplicity (if simple)	This COTS has a simple block diagram. Its function on the board is voltage regulation.
Hardware Function Allocated to device	Its isolates the required voltage for discrete signals.
COTS lifecycle data	COTS Status is active. It recommended for new designs
SEU Susceptibility	There is no SRAM or memory type structure that can be affected by soft error. SEU Sensitivity is low.
Errata Sheet Analysis or Quality, reliability & packaging data	There is no errata sheet.
Operational environmental conditions	Operating Junction Temperature -40 +125°C.
 	 
Device ID	TPS79901DRVR
Manufacturer	Texas Instruments
Circuit Board	BMB
Class (Simple or Complex)	Simple
Proofs of simplicity (if simple)	This COTS has a simple block diagram. Its function on the board is voltage regulation.
Hardware Function Allocated to device	It provides the necessary voltage regulation for discrete signals.
 	 
COTS lifecycle data	COTS Status is active. It recommended for new designs
SEU Susceptibility	When the block diagram of the product is examined, there is no SRAM or memory type structure that can be affected by soft error. SEU Sensitivity is low.
Errata Sheet Analysis or Quality, reliability & packaging data	Medium. It has a Safety Manual. In this manual, failure rate estimation, qualitative and quantitative failure analysis are available.
Operational environmental conditions	Operating Junction Temperature -55 +150 °C.
 	 
Device ID	TPS61040QDBVRQ1
Manufacturer	Texas Instruments
Circuit Board	BMB
Class (Simple or Complex)	Simple
Proofs of simplicity (if simple)	This COTS has a simple block diagram. Its function on the board is voltage regulation.
Hardware Function Allocated to device	It provides the necessary voltage regulation for the analogue SOC circuit.
COTS lifecycle data	COTS Status is active. It recommended for new designs.
SEU Susceptibility	Medium. It has a Safety Manual. In this manual, failure rate estimation, qualitative and quantitative failure analysis are available.
Errata Sheet Analysis or Quality, reliability & packaging data	There is no errata sheet. IC includes Quality, reliability and packaging data analysis by manufacturer.
Operational environmental conditions	Operating Temperature -40 +125°C.
 	 
Device ID	TPS7A9401DSCR
Manufacturer	Texas Instruments
Circuit Board	BMB
Class (Simple or Complex)	Simple
Proofs of simplicity (if simple)	This COTS has a simple block diagram. Its function on the board is voltage regulation.
Hardware Function Allocated to device	It provides the necessary voltage regulation for the analogue SOC circuit.
COTS lifecycle data	COTS Status is active. It recommended for new designs.
SEU Susceptibility	Medium. It has a Safety Manual. In this manual, failure rate estimation, qualitative and quantitative failure analysis are available.
Errata Sheet Analysis or Quality, reliability & packaging data	There is no errata sheet. IC includes Quality, reliability and packaging data analysis by manufacturer.
Operational environmental conditions	Operating Temperature -40 +125°C.
 	 
Device ID	TPS70933DBVR
Manufacturer	Texas Instruments
Circuit Board	BMB
Class (Simple or Complex)	Simple
Proofs of simplicity (if simple)	This COTS has a simple block diagram. Its function on the board is voltage regulation.
Hardware Function Allocated to device	It provides the necessary voltage regulation for the analogue SOC circuit.
COTS lifecycle data	COTS Status is active. It recommended for new designs.
SEU Susceptibility	Medium. It has a Safety Manual. In this manual, failure rate estimation, qualitative and quantitative failure analysis are available.
Errata Sheet Analysis or Quality, reliability & packaging data	There is no errata sheet. IC includes Quality, reliability and packaging data analysis by manufacturer.
Operational environmental conditions	Operating Temperature -40 +125°C.
 	 
Device ID	ISO7760QDBQQ1
Manufacturer	Texas Instruments
Circuit Board	BMB
Class (Simple or Complex)	Simple
Proofs of simplicity (if simple)	This COTS has a simple block diagram, it transmits the signal it receives to its input to its output in isolation. Its function in the card is to provide discrete signal isolation.
Hardware Function Allocated to device	It transfers the input and output discrete signals coming from and going to the MCU to the communication connector in isolation.
COTS lifecycle data	COTS Status is active. 
SEU Susceptibility	Medium. It has a Safety Manual. In this manual, failure rate estimation, qualitative and quantitative failure analysis are available.
Errata Sheet Analysis or Quality, reliability & packaging data	There is no errata sheet. IC includes Quality, reliability and packaging data analysis by manufacturer.
Operational environmental conditions	Operating Temperature -40 +105°C.
 	 
Device ID	ISO7520CDW
Manufacturer	Texas Instruments
Circuit Board	BMB
Class (Simple or Complex)	Simple
Proofs of simplicity (if simple)	This COTS has a simple block diagram, it transmits the signal it receives to its input to its output in isolation. Its function in the card is to provide discrete signal isolation.
Hardware Function Allocated to device	It transfers the input and output discrete signals coming from and going to the MCU to the communication connector in isolation.
COTS lifecycle data	COTS Status is active. 
SEU Susceptibility	Medium. It has a Safety Manual. In this manual, failure rate estimation, qualitative and quantitative failure analysis are available.
Errata Sheet Analysis or Quality, reliability & packaging data	There is no errata sheet. IC includes Quality, reliability and packaging data analysis by manufacturer.
Operational environmental conditions	Operating Temperature -40 +105°C.
Errata Sheet Analysis or Quality, reliability & packaging data	There is no errata sheet.
Operational environmental conditions	Operating Junction Temperature -40 +105 °C.
 	 
Device ID	HI-8597PSTF
Manufacturer	HOLT
Circuit Board	BMB
Class (Simple or Complex)	Simple
Proofs of simplicity (if simple)	This COTS has a simple block diagram. 
 	It doesn't have multiple functional elements that can interact with each other
 	It has a single functional mode
Hardware Function Allocated to device	Convert Logic Level Signals to ARINC429 Level.
 	Provide ARINC429 Signals to Battery Communication Connector
COTS lifecycle data	COTS Status is active. It recommended for new designs. Product Longevity is >10 years
SEU Susceptibility	There is no SRAM or memory type structure that can be affected by soft error. SEU Sensitivity is low.
Errata Sheet Analysis	There is no errata sheet.
Operational environmental conditions	Operating Junction Temperature -55 +125 °C.
 	 
Device ID	LP5009RUKR
Manufacturer	Texas Instruments
Circuit Board	BMB
Class (Simple or Complex)	Simple
Proofs of simplicity (if simple)	This COTS has a simple block diagram. Its function on the board is voltage regulation.
Hardware Function Allocated to device	It is used to generate the necessary voltage for the MCU and communication.
COTS lifecycle data	COTS Status is active. It recommended for new designs.
SEU Susceptibility	Medium. It has a Safety Manual. In this manual, failure rate estimation, qualitative and quantitative failure analysis are available.
Errata Sheet Analysis or Quality, reliability & packaging data	There is no errata sheet. IC includes Quality, reliability and packaging data analysis by manufacturer.
Operational environmental conditions	Operating Temperature -40 +150°C.
 	 
Device ID	AB0815-T3
Manufacturer	Abracon LLC
Circuit Board	BMB
Class (Simple or Complex)	Simple
Proofs of simplicity (if simple)	This COTS has a simple block diagram. 
 	It doesn't have multiple functional elements that can interact with each other
 	It has a single functional mode
Hardware Function Allocated to device	It provides real time clock to record the battery status in real time.
COTS lifecycle data	COTS Status is active. 
SEU Susceptibility	Medium
Errata Sheet Analysis or Quality, reliability & packaging data	There is no errata sheet.
Operational environmental conditions	Operating Junction Temperature -40 +85 °C.
 	 
Device ID	ADUM1250ARZ
Manufacturer	Analogue Devices Inc.
Circuit Board	BMB, CONTROL
Class (Simple or Complex)	Simple
Proofs of simplicity (if simple)	This COTS has a simple block diagram. It is used for communication isolation.
Hardware Function Allocated to device	It provides isolated communication between BMB and modules.
COTS lifecycle data	COTS Status is active.
SEU Susceptibility	Medium. It has a Safety Manual. In this manual, failure rate estimation, qualitative and quantitative failure analysis are available.
Errata Sheet Analysis or Quality, reliability & packaging data	There is no errata sheet. IC includes safety report by manufacturer.
Operational environmental conditions	Operating Temperature -40 +105°C.
 	 
Device ID	ADG1609BRUZ-REEL7
Manufacturer	Analog Devices
Circuit Board	BMB
Class (Simple or Complex)	Simple
Proofs of simplicity (if simple)	This COTS has a simple block diagram. It simply multiplies the signals it receives from its input in a controlled manner.
Hardware Function Allocated to device	It provides communication line duplication to enable communication of each module with the MCU.
COTS lifecycle data	COTS Status is active.
SEU Susceptibility	Medium. It has a Safety Manual. In this manual, failure rate estimation, qualitative and quantitative failure analysis are available.
Errata Sheet Analysis or Quality, reliability & packaging data	There is no errata sheet. IC includes Quality, reliability and packaging data analysis by manufacturer.
Operational environmental conditions	Operating Temperature -40 +125°C.
 	 
Device ID	TMUX1308BQBR
Manufacturer	Texas Instruments
Circuit Board	BMB
Class (Simple or Complex)	Simple
Proofs of simplicity (if simple)	This COTS has a simple block diagram. It simply multiplies the signals it receives from its input in a controlled manner.
Hardware Function Allocated to device	It makes each module active or passive by multiplying the signal it receives from the MCU.
COTS lifecycle data	COTS Status is active. It recommended for new designs.
SEU Susceptibility	Medium. It has a Safety Manual. In this manual, failure rate estimation, qualitative and quantitative failure analysis are available.
Errata Sheet Analysis or Quality, reliability & packaging data	There is no errata sheet. IC includes Quality, reliability and packaging data analysis by manufacturer.
Operational environmental conditions	Operating Temperature -40 +125°C.
 	 
Device ID	BQ771824DPJR
Manufacturer	Texas Instruments
Circuit Board	Monitor Board
Class (Simple or Complex)	Simple
Proofs of simplicity (if simple)	This COTS has a simple block diagram. Its function on the board is to sense the voltages of the module cells.
Hardware Function Allocated to device	It detects the cell voltages in each module and compares it with the reference voltage value.
COTS lifecycle data	COTS Status is active. 
SEU Susceptibility	Medium. It has a Safety Manual. In this manual, failure rate estimation, qualitative and quantitative failure analysis are available.
Errata Sheet Analysis or Quality, reliability & packaging data	There is no errata sheet. IC includes Quality, reliability and packaging data analysis by manufacturer.
Operational environmental conditions	Operating Temperature -40 +150°C.
 	 
Device ID	MAX16150AUT+T
Manufacturer	Analog Devices
Circuit Board	Monitor Board
Class (Simple or Complex)	Simple
Proofs of simplicity (if simple)	This COTS has a simple block diagram. It works as a simple switch.
Hardware Function Allocated to device	Activate or deactivate the modules with the signal received from the MCU.
COTS lifecycle data	COTS Status is active. It recommended for new designs.
SEU Susceptibility	Medium. It has a Safety Manual. In this manual, failure rate estimation, qualitative and quantitative failure analysis are available.
Errata Sheet Analysis or Quality, reliability & packaging data	There is no errata sheet. IC includes Quality, reliability and packaging data analysis by manufacturer.
Operational environmental conditions	Operating Temperature -40 +125°C.
 	 
Device ID	MIC5201-3.3YM5-TR
Manufacturer	Microchip Technology
Circuit Board	Monitor Board
Class (Simple or Complex)	Simple
Proofs of simplicity (if simple)	This COTS has a simple block diagram. It works as a DC to buck converter.
Hardware Function Allocated to device	It will be used to produce the isolated 5 volts required for the control card.
COTS lifecycle data	COTS Status is active. It recommended for new designs.
SEU Susceptibility	Medium. It has a Safety Manual. In this manual, failure rate estimation, qualitative and quantitative failure analysis are available.
Errata Sheet Analysis or Quality, reliability & packaging data	There is no errata sheet. IC includes Quality, reliability and packaging data analysis by manufacturer.
Operational environmental conditions	Operating Temperature -40 +125°C.
 	 
Device ID	SN74LVC1G02DBVR
Manufacturer	Texas Instruments
Circuit Board	Monitor Board
Class (Simple or Complex)	Simple
Proofs of simplicity (if simple)	This COTS is a simple logic gate. It logically compares the incoming signals and produces output.
Hardware Function Allocated to device	It logically compares the input signals from analogue protections and the MCU and produces an output signal.
COTS lifecycle data	COTS Status is active. 
SEU Susceptibility	Medium. It has a Safety Manual. In this manual, failure rate estimation, qualitative and quantitative failure analysis are available.
Errata Sheet Analysis or Quality, reliability & packaging data	There is no errata sheet. IC includes Quality, reliability and packaging data analysis by manufacturer.
Operational environmental conditions	Operating Temperature -40 +125°C.
 	 
Device ID	CD74AC10M96
Manufacturer	Texas Instruments
Circuit Board	Monitor Board
Class (Simple or Complex)	Simple
Proofs of simplicity (if simple)	This COTS is a simple logic gate. It logically compares the incoming signals and produces output.
Hardware Function Allocated to device	It logically compares the input signals from analogue protections and the MCU and produces an output signal.
COTS lifecycle data	COTS Status is active. 
SEU Susceptibility	Medium. It has a Safety Manual. In this manual, failure rate estimation, qualitative and quantitative failure analysis are available.
Errata Sheet Analysis or Quality, reliability & packaging data	There is no errata sheet. IC includes Quality, reliability and packaging data analysis by manufacturer.
Operational environmental conditions	Operating Temperature -40 +125°C.
 	 
Device ID	CD74HC4075PWR
Manufacturer	Texas Instruments
Circuit Board	Monitor Board
Class (Simple or Complex)	Simple
Proofs of simplicity (if simple)	This COTS is a simple logic gate. It logically compares the incoming signals and produces output.
Hardware Function Allocated to device	It logically compares the input signals from analogue protections and the MCU and produces an output signal.
COTS lifecycle data	COTS Status is active. 
SEU Susceptibility	Medium. It has a Safety Manual. In this manual, failure rate estimation, qualitative and quantitative failure analysis are available.
Errata Sheet Analysis or Quality, reliability & packaging data	There is no errata sheet. IC includes Quality, reliability and packaging data analysis by manufacturer.
Operational environmental conditions	Operating Temperature -40 +125°C.
 	 
Device ID	SN74LVC1G17DBVR
Manufacturer	Texas Instruments
Circuit Board	Monitor Board
Class (Simple or Complex)	Simple
Proofs of simplicity (if simple)	This COTS is a simple logic gate. It logically compares the incoming signals and produces output.
Hardware Function Allocated to device	It logically compares the input signals from analogue protections and the MCU and produces an output signal.
COTS lifecycle data	COTS Status is active. 
SEU Susceptibility	Medium. It has a Safety Manual. In this manual, failure rate estimation, qualitative and quantitative failure analysis are available.
Errata Sheet Analysis or Quality, reliability & packaging data	There is no errata sheet. IC includes Quality, reliability and packaging data analysis by manufacturer.
Operational environmental conditions	Operating Temperature -40 +125°C.
 	 
Device ID	INA190A1QDDFRQ1
Manufacturer	Texas Instruments
Circuit Board	Control Board
Class (Simple or Complex)	Simple
Proofs of simplicity (if simple)	This COTS has a simple block diagram. This IC only amplifies the voltage it reads.
Hardware Function Allocated to device	It increases the voltage on the heater current senses to measure the heater current.
COTS lifecycle data	COTS Status is active. It recommended for new designs.
SEU Susceptibility	Medium. It has a Safety Manual. In this manual, failure rate estimation, qualitative and quantitative failure analysis are available.
Errata Sheet Analysis or Quality, reliability & packaging data	There is no errata sheet. IC includes Quality, reliability and packaging data analysis by manufacturer.
Operational environmental conditions	Operating Temperature -40 +150°C.
 	 
Device ID	DAC53701DSGR
Manufacturer	Texas Instruments
Circuit Board	BMB
Class (Simple or Complex)	Simple
Proofs of simplicity (if simple)	This COTS has a simple block diagram. This IC only converts digital signal from MCU to analogue signal
Hardware Function Allocated to device	It generates a reference voltage to the current limiting circuit with the signal from the MCU.
COTS lifecycle data	COTS Status is active.
SEU Susceptibility	Medium. It has a Safety Manual. In this manual, failure rate estimation, qualitative and quantitative failure analysis are available.
Errata Sheet Analysis or Quality, reliability & packaging data	There is no errata sheet. IC includes Quality, reliability and packaging data analysis by manufacturer.
Operational environmental conditions	Operating Temperature -40 +125°C.
 	 
Device ID	INA228AQDGSRQ1
Manufacturer	Texas Instruments
Circuit Board	Control Board, BMB
Class (Simple or Complex)	Simple
Proofs of simplicity (if simple)	This COTS has a simple block diagram. It digitally transmits the analogue voltage and temperature value it detects to the MCU. It simply compares the parameter value determined with the value it detects as analogue and produces an output signal.
Hardware Function Allocated to device	This IC detects the current and transmits it to the MCU. It detects the current values of each module and the current and voltage values of the BMB card and transmits them to the MCU. It also compares for analogue protection.
COTS lifecycle data	COTS Status is active. It recommended for new designs.
SEU Susceptibility	Medium. It has a Safety Manual. In this manual, failure rate estimation, qualitative and quantitative failure analysis are available.
Errata Sheet Analysis or Quality, reliability & packaging data	There is no errata sheet. IC includes Quality, reliability and packaging data analysis by manufacturer.
Operational environmental conditions	Operating Temperature -40 +150°C.
 	 
Device ID	ADS7138QRTERQ1
Manufacturer	Texas Instruments
Circuit Board	Control Board, Monitor Board
Class (Simple or Complex)	Simple
Proofs of simplicity (if simple)	This COTS has a simple block diagram. This IC converts the analogue data it detects into digital data.
Hardware Function Allocated to device	This IC detects the limiter current sensor, cell temperatures and heater current sensor data and transmits it digitally and to the MCU. With a simple comparison structure, it compares the referenced parameter with the parameter it detects.
COTS lifecycle data	COTS Status is active. It recommended for new designs.
SEU Susceptibility	Medium. It has a Safety Manual. In this manual, failure rate estimation, qualitative and quantitative failure analysis are available.
Errata Sheet Analysis or Quality, reliability & packaging data	There is no errata sheet. IC includes Quality, reliability and packaging data analysis by manufacturer.
Operational environmental conditions	Operating Temperature -40 +125°C.
 	 
Device ID	ADA4097-2BCPZ
Manufacturer	Analogue Devices Inc.
Circuit Board	Control Board
Class (Simple or Complex)	Simple
Proofs of simplicity (if simple)	This COTS has a simple block diagram. It does not take any action and amplifies the signal it detects.
Hardware Function Allocated to device	Its function on the board is to differentially detect the limiter current.
COTS lifecycle data	COTS Status is active. It recommended for new designs.
SEU Susceptibility	Medium. It has a Safety Manual. In this manual, failure rate estimation, qualitative and quantitative failure analysis are available.
Errata Sheet Analysis or Quality, reliability & packaging data	There is no errata sheet. IC includes Quality, reliability and packaging data analysis by manufacturer.

6.6	New Technologies to Be Used	
Any new technology design concept will not be implemented for the lithium ion battery.
6.7	Hardware Safety, Redundancy and Partitioning
 Lithium ion battery has DAL A functions. An architectural mitigation is planned by partitioning the functions. The FDALs of the functions are shown in the FHA. FHA and FTA will be performed for critical system functions. These analyses will be included in RP-PSSA-001-0003
The lithium ion battery has functional redundancy, fault tolerance and fail-safe situations are explained in this PHAC.
Partitioning will be realized by paying attention to the following items during the design.
•	The design will be divided into smaller compartments and functional isolation will be ensured.
•	Design compartments will be verifiable in isolation from each other.
•	Design compartments will be traceable as input and output.
•	According to the FHA analysis, there will be hardware redundancy in the design for critical functions.
•	According to FHA analysis, hardware with critical functions will work with software.
•	Component-based redundancy will be provided in critical hardware items according to FHA analysis.
•	OTD, OTC, COV, CUV, MOV, MUV, OCD SCD functions in battery are inherently functional redundant. AOT temperature protection will provide redundancy to the OTC and OTD protections provided by the software, both during charging and discharging. Evenif the MCU is gone, these protections can be provided as hardware in isolation.
6.8	Single Event Upset Planning
Single Event Upset (SEU) occur when atmospheric radiation, comprising high energy particles, collide with specific locations on semiconductor devices contained in aircraft systems. Memory devices, and microprocessors are most sensitive to SEU.
6.8.1	Initial Assessment
FHA will be reviewed. For each system or function with one or more failure conditions classified as Catastrophic or Hazardous, a list shall be established that includes all equipment that may contribute to the failure condition in the system.
6.8.2	SEU Analysis
The SEU sensitivity level of each component shall be determined using the datasheet of the respective component. If the datasheet does not contain sufficient information, an SEU sensitivity determination shall be made according to the type of component, guided by IEC 62396 Part 1.
6.8.3	Qualitative assessment process
A qualitative assessment of potentially affected components will be carried out according to the SEU Analysis. These components will be reviewed and the functions that the components are used for and affect. If qualitative mitigation is possible by design, it will be assessed and implemented.
6.8.4	Quantitative assessment process
For the remaining components where no mitigation or only partial mitigation against the effects of the SEU has been identified, a quantitative assessment shall be carried out. 
Where the quantitative assessment shows that the probability of the component being affected by SEU is unacceptably high compared to the classification of the failure, the following options shall be considered 
•	Redesign of the component or use of a different component  
•	Redesign of the architecture to include additional mitigation(s) 
 
7	CERTIFICATION CONSIDERATIONS
7.1	Certification Basis 
Llithium ion battery development will be predicted based on per EASA AMC 20-152A, 
Table 11 and specific guidance defined given in the following Certification Memorandums will be followed for design assurance and certification aspects associated with the use of airborne electronic hardware. 
Table 11 AEH Certification Memorandums
NO	IDENTIFICATION NO	REV/DATE	TITLE	SOURCE
1.             	DO-254	19 April 2000	Design Assurance Guidance for Airborne Electronic Hardware	RTCA
2.	AMC 20-152A	5 November 2003	Development Assurance for Airborne Electronic Hardware (AEH)	EASA
3.	MIL-STD-516C	12 December 2014	Department of Defence Handbook: Airworthiness Certification Criteria	
	
7.2	Hardware Level Determination
FFPA will be performed in accordance with DO-254 Appendix B. Hardware Item DALs determined according to the criticalities of the failure conditions which are provided in the RP-PSSA-001-0003 TLUH Preliminary System Safety Assessment. The analysis and results are shared in the RP-PSSA-001-0003 TLUH Preliminary System Safety Assessment. The highest hardware level is B. The hardware is analysed part by part in the RP-PSSA-001-0003 TLUH Preliminary System Safety Assessment
7.3	 Hardware Means of Compliance
The TLUH battery is based on DO-254 objective lenses with compatibility tools recommended for AEH devices used in accordance with AMC 20-152. DO-254 lenses and AMC 20-152 lenses are listed in Appendix A and Appendix B at PHAC. Design assurance levels for AEH devices have been determined based on system safety considerations. Architectural reduction and subsequent sections are used to support dedicated branches. The branch levels proposed for the AEH device used in this application are shown in Table 7.
8	HARDWARE DESIGN LIFECYCLE
8.1	Team Member Responsibilities
Team Members for the project and their responsibilities are described in PL-DO-001-0004 Design Organisation Interface Document.
8.2	Processes
The PL-HD-001-0003 Hardware Design Plan describes the life-cycle processes in detail. What follows is a brief summary.
 It describes the hardware design processes of the project and the coordination of these processes. The following processes occur sequentially: 
•	Planning Process: The planning process involves assigning the project's technical team, defining main objectives, and collaborating with stakeholders like customers, quality, production, design, and program management.
•	Requirements Capture Process: This process identifies, defines, and documents various types of requirements, including safety, functional, customer, operational, performance, physical, installation, maintainability, interface, and other certification-related requirements.
•	Conceptual Design Process: Conceptual design aims to create a high-level design concept aligned with requirements, utilizing tools such as functional block diagrams, design descriptions, and sketches.
•	Detailed Design Process: Detailed design aims to develop a detailed design concept consistent with high-level requirements and conceptual design data.
•	Implementation Process: Implementation involves creating or fabricating a system element according to its detailed description, using specified materials, processes, arrangements, and design documentation.
•	Production Transition Process: This process establishes a baseline for replicating the hardware item consistently and identifies manufacturing requirements related to safety.
•	Testing Process Testing's purpose is to prove that the product performs in compliance with key attributes, with engineers conducting electrical tests, elemental analysis, and more.
•	Validation Process: Validation provides evidence that a system or element fulfils specified requirements and characteristics, involving preparation, execution, and results management.
•	Verification Process: Verification provides evidence that a system fulfils business objectives and stakeholder requirements, involving planning, execution, and results management.
The following processes are concurrent with the sequential processes:
•	Configuration Management Process: Configuration management involves implementing and controlling changes related to design and production activities, maintaining compliance with plans and standards.
•	Process Assurance: Process assurance ensures compliance of life cycle processes and hardware design data with approved plans, standards, and requirements.
•	Certification Liaison Process: The certification liaison process aims to establish communication with the certification authority, gain agreement on means of compliance, and provide evidence of compliance.

8.3	Design Procedures
The design procedure processes are described and detailed in PR-AV-001 Design Procedure (Aviation).
8.4	Hardware Design Methods
Methods are defined and explained by the PL-HD-001-0003 Hardware Design Plan. Hardware design methods include the following steps: 
•	Requirements Capture and Specification Methods: System requirements are meticulously analysed and determined together. These requirements apply in accordance with the PR-AV-008 Hardware Requirement Standard.
•	Conceptual Design: The basic framework of aircraft electronic equipment is created; safety aspects are considered. 
•	Detailed Design: Hardware specifications are developed by detailing the conceptual design, and safety and quality requirements are aligned. 
•	Synthesis Techniques: The detailed design is expressed as a netlist and translated into hardware components.
•	Means of providing feedback and interaction: The PL-HD-001-0001 Hardware Design Plan document explains in detail the ways to provide feedback and interaction between hardware processes and system and software processes. These feedback mechanisms are briefly as follows: Regular meetings, Common data and document sharing, change management and version control tools, etc.
•	 Implementation: It is implemented in accordance with the safety and quality requirements of detailed design. 
•	Architectural Mitigation Management: Weaknesses for critical functions are identified and addressed through redundancy or design improvements.
•	 Production Transition: Processes are determined for the transition to the production process, document audits and production planning are made.
8.5	Hardware Standards
The design, development, validation and verification activities of the products are carried out according to;
•	PR-AV-007 Hardware Design Standard.
•	PR-AV-008 Hardware Requirement Standard
•	PR-AV-009 Validation and Verification Standard
•	PR-AV-010 Hardware Archive Standard
The tools used to provide feedback are mentioned in PR-AV-007 Hardware Design Standard.
8.6	Activities
The activities are defined by the PL-HD-001-0003 Hardware Design Plan. In brief each development process (Planning, Requirements Capture, Conceptual Design, etc.) has an associated checklist of activities, managed by the lead hardware developer. The checklist for each development process is completed before proceeding to the next development process. The process checklists include: development of data items, review and release of data items, etc

9	HARDWARE DESIGN LIFECYCLE DATA 
The hardware processes described above produce output data that can be used for verification or as input to other hardware processes. This data shall be in the form of documents, checklist, drawings or any other type of data generated by the process. This data can be on paper or electronic media. The identification and control of hardware life cycle data is summarized in Table 12.
After the hardware life cycle data is produced, it is shared with TUSAS via T-Drive. It is reviewed with the authority in SOI audits.
Table 12 Hardware Control Categories
RTCA/DO-254	Data Item Title	Acronym	Control Category	Process Out	Submit
10.1.1	Plan for Hardware Aspects of Certification	PHAC	HC1	Planning	Yes
10.1.2	Hardware Design Plan	HDP	HC2	Planning	
10.1.3
10.1.4	Hardware Validation and Verification Plan	HVVP	HC2	Planning	Yes
10.1.5	Hardware Configuration Management Plan	HCMP	HC1	Planning	
10.1.6	Hardware Process Assurance Plan	HPAP	HC2	Planning	
10.2.1	Hardware Requirements Standards	HRS	HC2	Planning	
10.2.2	Hardware Design Standards	HDS	HC2	Planning	
10.2.3	Hardware Validation and Verification Standards	HVVS	HC2	Planning	
10.2.4	Hardware Archive Standards	HAS	HC2	Planning	
10.3.1	Hardware Requirements Data	Hardware Requirement Document (HWRD)	HC1	Planning	
10.3.2.1	Conceptual Design Data	Hardware Design Document (HDD)	HC2	Conceptual Design	
10.3.2.2.1	Top-Level Drawing		HC1	Detailed Design	Yes
10.3.2.2.2	Assembly Drawing		HC1	Detailed Design	
10.3.2.2.3	Installation Control Drawings		HC1	Detailed Design	
10.3.2.2.4	Hardware Interface Data		HC1	Verification	
10.4.1	Hardware Traceability Data	-	HC2	Verification	
10.4.2	Hardware Review and Analysis Procedures	-	HC1	Verification	
10.4.3	Hardware Review and Analysis Results	-	HC2	Verification	
10.4.4	Hardware Test Procedures	-	HC1	Verification	
10.4.5	Hardware Test Results	-	HC2	Verification	
10.5	Hardware Acceptance Test Criteria	HATC	HC2	Verification	
10.6	Problem Reports	-	HC2	Verification	
10.7	Hardware Configuration Management Records	HCMR	HC2	Configuration Management	
10.8	Hardware Process Assurance Records	HPAR	HC2	Verification	
10.9	Hardware Accomplishment Summary	HAS	HC1	Verification	Yes

9.1	Trace Data
All Design data will be traced and stored according to ASPİLSAN Enerji configuration management policy as described within PL-HCM-001-0003 Hardware Configuration Management Plan (HCMP).
10	ADDITIONAL CONSIDERATIONS 
10.1	Use of Previously Developed Hardware
There is no previously developed for this project. This plan covers the new development approach of ASPİLSAN Enerji for this project. 
10.2	Data to Be Reused
There is no previous use data for this product. All design and development activities will be carried out by relevant standards and requirements.
10.3	Use of Commercial-Off-The-Shelf (COTS) Components
COTS components are used to perform important functions of the product. During the design, the suitability of the selected components for the function will be verified by the reviews of the hardware designers in the team. In addition, hardware software interfaces will be specified in Hardware Interface Data. The reviews of the software developers in the team will verify that these interfaces are suitable for the relevant functions.
All precautions taken for the unused functions of the selected components will be specified in the deliverables of the Detailed Design phase.
How these components are selected, procurement, where and how the data package is stored, procedures for simple or complex COTS are all defined in the PL-ECMP-001-0001 Electronic Component Management Plan (ECMP).
Common Mode Analysis and Component Level Failure Mode Effect Critical Analysis will be performed as part of the safety assessment process. The results of these analyses will be shared in the RP-PSSA-001-0003 Preliminary System Safety Assessment document.
10.4	Modifiable Devices
Modifiable Device will not be used.
10.5	Simple Electronic Hardware (SEH)
Assessment will be made according to AMC-20-152. 
 
10.6	Commercial Off-The-Shelf (COTS) Microprocessors
According to DO254, simple COTS microprocessor will be used in this product. Detailed information about this COTS is given in document PL-PSA-001-0005. The process specified in the ECMP will also apply to this COTS. The verification for this COTS will be provided by board-based and LRU-based tests. The follow-up of the change processes in the COTS revision is specified in the PL-ECMP-001-0001 Electronic Component Management Plan (ECMP) document.
10.7	Design Assurance Considerations
As a result of the Functional Hazard Analysis (FHA), the design assurance of the battery is Level B. The hardware and software functional failure path was determined by top-down Fault Tree analysis according to DO 254 Annex B and ARP 4761 standard. Detailed analysis from Hardware Level FFPs to Circuit level FFPs and component level FFPs will be analysed in the RP-PSSA-001-0003 Preliminary System Safety Assessment document.
10.8	Tool Assessment and Qualification
The tools to be used for hardware design will be characterized according to the figure in Hata! Başvuru kaynağı bulunamadı..outputs of all tools will be assessed independently. No tool will be used for battery verification.

Figure 8 Design and Verification Tool Assessment and Qualification
The tools to be used, their type, qualification requirements and why they are used are stated in Table 13.

Table 13 Tools to Use
Tool Name	Altium Designer
Tool Version	22
Tool Type (Design / Verification)	Design
Is tool qualification needed? (Yes or No)	No
Why it is not needed (If no qualification needed)	This tool is only needed for drawing the cards, not for production quality. There is no simulation that will play a critical role in the operation of the product. Schematic and PCB design program used by all designers. Tool output will be verified by an independent verification method.
Tool Name	Solidworks
Tool Version	2020 Premium
Tool Type (Design / Verification)	Design
Is tool qualification needed? (Yes or No)	No
Why it is not needed (If no qualification needed)	This tool is where the mechanical design of the battery is done. It does not run a simulation for safety critical functions of the battery. It is a common mechanical design program used by all designers. Tool output will be verified by an independent verification method.
 	 
Tool Name	LTSPICE
Tool Version	17.0.35.0
Tool Type (Design / Verification)	Analogue Simulation
Is tool qualification needed? (Yes or No)	No
Why it is not needed (If no qualification needed)	It is a simulation tool to be used during design. It is a common tool. Tool output will be verified by an independent verification method.
 	 
Tool Name	PSPICE FOR TI
Tool Version	17.04.2022
Tool Type (Design / Verification)	Filter Design and Simulation
Is tool qualification needed? (Yes or No)	No
Why it is not needed (If no qualification needed)	It is a simulation tool to be used during design. It is a common tool. Tool output will be verified by an independent verification method.
10.9	Hardware Tool Assessment and Qualification Process
Hardware design tools are defined in section 10.6 and hardware verification tools are defined in PL-HVVP-001-0003. Qualification of the design tools is not required; all tool outputs are verified through review, simulation and/or hardware test. The hardware verification report will include details of usage of the design and verification tools in the current previous certification programs.
10.10	Hardware Tool Assessment and Qualification Data
For design tools, a lifecycle analogue to DO-178C or DO-254 will be required if the tool fully satisfies an objective and the outputs are not checked or verified.
For verification tools, the operational requirements will be defined and a set of test cases developed to verify that the tool meets its operational requirements under normal operating conditions. Operational requirements, the qualification test cases, and the qualification test results will be provided in the tool qualification reports.
10.11	Use of Suppliers, Sub-Tier Suppliers and Off-Shore Facilities
There are no suppliers within the project. In case of working with a supplier, information will be provided.
10.12	Deviations and Modifications to Plans
In case of deviations or changes in the plans, ASPİLSAN Enerji will inform the TA as defined in PL-HCM-001-0001 Hardware Configuration Management Plan (HCMP).
11	ALTERNATIVE METHODS
No alternative methods will be used.
12	CERTIFICATION SCHEDULE 
12.1	Stage of Involvement Audits and Project Milestones
This section should include activities of software lifecycle SOI reviews can be planned. This plan is prepaired for TLUH.  The certification schedule of the battery should match with TLUH schedule.  SOI Reviews that covers AE contrats with TA are listed below.
SOI#1 2024 
SOI#2 2024
SOI#3 2024
SOI#4 2025
 
APPENDIX A: DO-254 COMPLIANCE MATRIX
Objective	DO-254	PHAC
Planning Process Objectives	4.1	
1.	The hardware design life cycle processes are defined.		8.2

2.	Standards are selected and defined.		8.2

3.	The hardware development and verification environments are selected or defined.		8.2

4.	The means of compliance of the hardware design assurance objectives, including strategies identified using guidance in Section 2.3.4, are proposed to the certification authority.		8.2

Requirements Capture Objectives	5.1.1	
1.	Requirements are identified, defined and documented. This includes allocated requirements from the PSSA and derived requirements from the hardware safety assessment.		8.2

2.	Derived requirements produced are fed back to the appropriate process.		8.2

3.	Requirement omissions and errors are provided to the appropriate process for resolution.		8.2

Conceptual Design Objectives	5.2.1	
1.	The hardware item conceptual design is developed consistent with its requirements.		8.2

2.	Derived requirements produced are fed back to the requirements capture or other appropriate processes.		8.2

3.	Requirement omissions and errors are provided to the appropriate processes for resolution.		8.2

Detailed Design Objectives	5.3.1	
1.	The detailed design is developed from the hardware item requirements and conceptual design data.		8.2

2.	Derived requirements are fed back to the conceptual design process or other appropriate processes.		8.2

3.	Requirement omissions or errors are provided to the appropriate processes for resolution.		8.2

Implementation Objectives	5.4.1	
1.	A hardware item is produced which implements the hardware detailed design using representative manufacturing processes.		8.2

2.	The hardware item implementation, assembly and installation data are complete.		8.2

3.	Derived requirements are fed back to the detailed design process or other appropriate processes.		8.2

4.	Requirement omissions and errors are provided to the appropriate processes for resolution.		8.2

Production Transition Objectives	5.5.1	
1.	A baseline is established that includes all design and manufacturing data needed to support the consistent replication of the hardware item.		8.2

2.	Manufacturing requirements related to safety are identified and documented and manufacturing controls are established.		8.2

3.	Derived requirements are fed back to the implementation process or other appropriate processes.		8.2

4.	Errors and omissions are provided to the appropriate processes for resolution.		8.2

Validation Process Objectives	6.1.1	
1.	Derived hardware requirements against which the hardware item is to be verified are correct and complete.		8.2

2.	Derived requirements are evaluated for impact on safety.		8.2

3.	Omissions and errors are fed back to the appropriate processes for resolution.		8.2

Verification Process Objectives	6.2.1	
1.	Evidence is provided that the hardware implementation meets the requirements.		8.2

2.	Traceability is established between hardware requirements, the implementation, and the verification procedures and results.		8.2

3.	Acceptance test criteria are identified, can be implemented and are consistent with the hardware design assurance levels of the hardware functions.		8.2

4.	Omissions and errors are fed back to the appropriate processes for resolution.		8.2



APPENDIX B: AC-20-152 COMPLIANCE MATRIX
Objective ID	Related AMC 20-152A Objective	PHAC	Outputs
COTS-1
	The applicant should assess the complexity of the COTS devices used in the design according to the high-level criteria of Section 6.3, and document the list of relevant devices (see Note 1), including the classification rationale, in the PHAC or any related hardware planning document. 
Note 1: The applicant is not expected to assess the complete bill of material to satisfy the above objective, but only those devices that are relevant for the classification, including devices that are at the boundary between simple and complex. The resulting classification (simple or complex) for those devices that are at the boundary and those that are definitely complex should be documented. 
Note 2: A classification rationale is required for those devices that are at the boundary (meeting a part of the high-level criteria) and are classified as simple.  	6.5
In the specified section lists the COTS devices used, with evidence of complex simple classification. 
COTS-2	The applicant should ensure that an electronic component management process (ECMP) exists to address the selection, qualification, and configuration management of COTS devices. The ECMP should also address the access to component data such as the user manual, the datasheet, errata, installation manual, and access to information on changes made by the component manufacturer. As part of the ECMP, for devices contributing to hardware DAL A or B functions, the process for selecting a complex COTS device should consider the maturity of the COTS device and, where risks are identified, they should be appropriately mitigated. 
Note: Recognised industry standards describing the principles of electronic component management may be used to support the development of the ECMP. See Appendix B.	10.3
10.6
A draft ECMP document has been produced. It describes the processes currently in place.
COTS-3	When the complex COTS device is used outside the limits of the device manufacturer’s specification (such as the recommended operating limits), the applicant should establish the reliability and the technical suitability of the device in the intended application.	10.6
All COTS devices, including the microprocessor, are used within the recommended limits.
COTS-4	If the microcode is not qualified by the device manufacturer or if it is modified by the applicant, the applicant should ensure that a means of compliance for this microcode integrated within the COTS device is proposed by the appropriate process, and is commensurate with the usage of the COTS device. 
Note: The PHAC (or any other related planning document) should document the existence of the microcode and refer to the process (hardware, software, system) where it is addressed.	NA	
COTS-5	The applicant should assess the errata of the COTS device that are relevant to the use of the device in the intended application, and identify and verify the means of mitigation for those errata. If the mitigation means is not implemented in hardware, the mitigation means should be fed back to and verified by the appropriate process. 
Note: The above objective refers to any mitigation means (such as hardware, software, system, or other means).	6.5
10.3
10.6
Errata document is available for the microprocessor. An analysis report is planned for this document. This report will show that errors in errata do not affect the product.
COTS-6	The applicant should identify the failure modes of the used functions of the device and the possible associated common modes, and feed both of these back to the system safety assessment process.	6.7

COTS-7	The applicant should ensure that the usage of the COTS device has been defined and verified according to the intended function of the hardware. This also includes the hardware–software interface and the hardware to (other) hardware interface.
When a COTS device is used in a hardware DAL A or B function, the applicant should show that unused functions of the COTS device do not compromise the integrity and availability of the COTS device’s used functions.
Note 1: For unused functions of the COTS device, it is recommended that an effective deactivation means is used and verified, when available.
Note 2: Verification should be performed at an appropriate level (hardware, software, equipment).	10.3
Hardware Review and Analysis Results and Hardware Test Result documents will show the intended verification result in the objective.
COTS-8	If the complex COTS device contributes to DAL A or B functions, the applicant should develop and verify a means that ensures an appropriate mitigation is specified in the event of any inadvertent alteration of the ‘critical configuration settings’ of the COTS device.
Note: The mitigation means might be defined at the hardware, software, or system level, or a combination of these. The mitigation means may also be defined by the safety assessment process.	NA	
CBA-1	The applicant should have a process to address the development of CBAs that contain complex custom devices or complex COTS devices, in order to ensure that the CBA performs its intended function. The process should include requirements capture, validation, verification, and configuration management activities, and ensure an appropriate flow-down of requirements. See Appendix B for additional information. 
Note: The applicant’s process to address the development of the CBA may be defined together with the equipment process, when relevant.	8.2
The process according to the DO254 objectives is shown in defined section. Design lifecycle processes are described in detail in the HDP.


"
Yukarıdaki metni incele ve aşağıdaki soruların yukarıdaki nmetni kapsıyorsa metnin hangi başlık ve altbaşlığında herb bir sorunun cevabının olduğunu yaz.
Sorular: 
""1.Has the planning data been signed and put under CM (HC1 or HC2 as appropriate for the hardware level)? Verify there is objective evidence of coordination (e.g., authorized signatures) from all organizations controlled and affected by the hardware plans and standards.
2. Are plans, standards, design and verification environments cited complete, clear, and consistent (e.g., can the design and verification engineers follow them)?
3.If the plans and standards are followed, would this ensure that all applicable DO-254 objectives are met (i.e., do the plans and standards address how each of the applicable DO-254 objectives will be satisfied)?
4.Are the interfaces and communication channels with the hardware design processes addressed in the plans and well defined? Evaluate processes for flow down of system requirements (functional, performance, operational, safety-related, and system architecture safety features) and for clarifying ambiguous system requirements. Determine if the hardware verification process will be claiming “formal test credit” for testing conducted by the system verification and validation processes. If so, then what kind of credit, and how much credit will be granted?
5.Are the interfaces and communication channels with applicable hardware design and verification processes addressed in the plans and well defined? Evaluate the processes for documenting and communicating hardware dependencies and interactions with the system software and its development and verification processes, and for software dependencies on the hardware and its design and verification processes. Determine the process used to convey safety features (e.g., monitors, built in test, memory management unit, I/O device, processor features (cache, registers, priorities, schedulers, supervisor/user modes, etc.)) and software changes affecting the hardware processes, and how the hardware processes will address them.
6.Are there unique additional considerations associated with the project (unique alternative means or methods of compliance, unique approaches to design, verification, CM, PA), proposals that don’t comply with FAA national or Directorate policy or issue papers, etc.? If so:
• Have national or directorate hardware and systems personnel reviewed and approved any unique additional considerations?
• Is rationale for acceptance or rejection of developer/applicant’s proposals well documented?
7.Are issue papers or national/directorate policy required for any of the additional considerations? If so, do the plans and standards address how compliance with the issue papers and/or national/directorate policy will be achieved?
8.Are the means of compliance of the hardware design assurance objectives defined and are they commensurate with the design assurance level(s)?
9.Are such items as previously developed hardware, commercial-off-the shelf (COTS) hardware or COTS Intellectual Property, field-loadable logic, option-selectable hardware, product service experience, alternative methods of compliance, etc. identified and addressed in the plans?
10.If the developer plans on using previously developed hardware (PDH) for the current design, consider the following questions:
• If PDH from legacy systems is intended to be used, does the service experience of the system support reuse of its hardware?
• Are there any airworthiness directives, service bulletins, in-work National Transportation Safety Board safety recommendations, or unresolved problem reports with safety, functional, performance, operational or maintenance issues for the legacy system or any proposed PDH?
• Does the PDH have a satisfactory service experience?
• Does the developer intend to make any modifications to PDH? Are plans and processes defined for managing, controlling, and verifying those changes (in compliance with DO-254 section 11.3, 11.3.1-11.3.3)?
• Is the PDH or legacy hardware used in an identical manner and executed on the same system hardware and in the same environment as its previous uses?
• Was the PDH previously approved to DO-254?
11.Verify that hardware tools are identified and explained in the plans. Consider the following questions:
• Do the plans provide rationale for why tools do or do not need to be qualified (e.g., was the tool assessment and qualification process in section 11.4.1 discussed in the plans)?
• Is service experience claimed for the use of any tool? If so, has the tool changed or is it being used in the same way as previously used? Does the documented tool service experience justify and support the intended use for the current design?
12.Are tools to be qualified supported with a tool qualification plan (either in the PHAC or in a separate document)? Verify that tools are properly categorized into design or verification or multi-function tools. Verify that the plan for assessment and qualification of tools is documented and adequate for the specified tool use.

Note: Section 11.4 of DO-254 provides specific guidelines regarding tool qualification.
13.Is reverse engineering being planned for any PDH? If so:
• Has the rationale for reverse engineering been documented and adequately justified to the certification authority (typically in the “additional considerations” section of the PHAC)?
• Has the reverse engineering effort been planned (in the PHAC and other plans)?
• Are processes and procedures well defined?
• Is the reverse engineering life cycle documented?
• Does the reverse engineering approach meet DO-254 objectives?
• How will the requirements be created? Is the plan adequate?
• Do transition criteria and traceability exist? Are they adequate?
Note: See CAST-18, Reverse Engineering in Certification Projects, for specific certification concerns regarding reverse engineering. In some cases, an issue paper may be required, if the plans do not address the DO-254 objectives compliance. Available at:
http://www.faa.gov/aircraft/air_cert/design_approvals/air_software/cast/
14.Does the PHAC adequately address the proposed contents described in DO-254, Section 10.1.1? If not, where are the contents documented?
Note: If it is documented in another planning document, that document will need to be evaluated before the PHAC can be approved. Also, that data item should be configuration controlled to the same HC1 level as the PHAC.
15.Does the PHAC address the following questions regarding changes to plans and standards:
• Is a process in place to address changes to plans and standards that may occur throughout the design process?
• Are there plans and processes to address any deviations to plans and standards?
• Do the deviations require justification and rationale for why they are acceptable for this project?
• Will applicable aspects of the hardware plans, standards 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?
• Are the plans and standards under change control?
16.Does the hardware level proposed in the PHAC support the system safety assessment adequately? If the hardware level is lower than what the system safety assessment suggests, is there adequate justification (e.g., through FFPA, system architecture, safety feature, redundancy, fail safe design techniques, partitioning as described in Appendix B of DO-254)?

Note: This determination will likely require input from the systems engineer.
17. Does the PHAC address the additional and applicable considerations described in Appendix B of DO-254?
18.Does the PHAC define independence and describe the method for independence required for Level A and B hardware?
"