"3	APPLICABLE DOCUMENTS
3.1	Internal References
Table 1  Applicable Documents
Document No	Title
BL-SD-001-0006	System Description Document
BL-IC-001-0006	Interface Control Document
PL-DO-001-0002	Design Organization Interface Document
PL-HPA-001-0001	Hardware Process Assurance Plan
PL-HDP-001-0001	KAAN Hardware Design Plan
PL-HVVP-001-0001 	KAAN Hardware Validation Verification Plan
PL-ECMP-001-0001	Electronic Component Management Plan
PL-HCM-001-0001	Hardware Configuration Management Plan
RP-PSSA-001-0004	KAAN Preliminary System Safety Assessment
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-0001	Plan for Software Aspect of Certification

3.2	External References
The documents listed in Table 2 below 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 boards 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
°C	Celsius
A	Ampere
A/C	Aircraft
ADC	Analog to Digital Converter
AEH	Airborne Electronic Hardware
Ah	Ampere Hour
AOT	Analog 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
CPU	Central Processing Unit
CRC32	Cyclic Redundancy Checksum
CUV	Cell Undervoltage Discharge Protection
DAC	Digital to Analog Converter
DAL	Design Assurance Level
DC	Direct Current
DOID	Design Organization Interface Document
EASA	European Union Aviation Safety Agency
ECC	Error Correction Code
ECMP	Electronic Component Management Plan
EOL	End of Life in Regards to Final Battery Capacity
FFP	Functional Failure Path
FFPA	Functional Failure Path Analysis
FHA	Functional Hazard Assessment
FPGA	Field Programmable Gate Arrays
FTA	Fault Tree Analysis
HAS	Hardware Archive Standards
HATC	Hardware Acceptance Test Criteria
HC1 and HC2.	Hardware Control Categories 1 and 2.
HCMP	Hardware Configuration Management Plan
HCMR	Hardware Configuration Management Records
HDD	Hardware Design Document
HDL	Hardware Description Language
HDP	Hardware Design Plan
HDS	Hardware Design Standards
HPAP	Hardware Process Assurance Plan
HPAR	Hardware Process Assurance Records
HRS	Hardware Requirements Standards
HVVP	Hardware Validation Verification Plan
HVVS	Hardware Validation and Verification Standards
HWRD	Hardware Requirements Data
GPIO	General-Purpose Input/Output
I2C	Inter-Integrated Circuit
IC	Integrated Circuit
IEC	International Electrotechnical Commission
IP	Intellectual Property
Kbyte	Kilobyte
LED	Light Emitting Diodes
LFP	Lithium Iron Phosphate
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
PDR	Preliminary Design Review
PHAC	Plan for Hardware Aspect Certification
PLATFORM	Air Vehicle Management System
PSAC	Plan for Software Aspect of Certification
PSSA	Preliminary System Safety Assessment
PTC	Positive Temperature Coefficient
RAM	Random Access Memory
RTC	Real Time Clock
RTCA	Radio Technical Commission for Aeronautics
RTD	Resistance Temperature Detectors
SCD	Short Circuit Discharge Protection
SEH	Simple Electronic Hardware
SEU	Single Event Upset
SOC	State of Charge
SOH	State of Health
SOI	Stage Of Involvement
SPI	Serial Peripheral Interface
SRAM	Static Random Access Memory
TA	Turkish Aerospace
UART	Universal Asynchronous Receiver / Transmitter
V / mV	Volt / millivolt
VDC	Volts Direct Current
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-0001 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-0002 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.
 
Figure 1 ASPİLSAN Enerji Organization Chart  
5	SYSTEM OVERVIEW
5.1	System Top Level Diagram
28V DC Battery is a Line Replaceable Unit (LRU) for Power Storage System of KAAN Electrical Power System. Block Diagram of KAAN Power Storage System is shown in Figure 2.


Figure 2 Power Storage System Top Level Block Diagram

The main function of the 28VDC Battery is to power the 28VDC Bus during emergency operation of the aircraft. The 28VDC Battery will be developed to meet all equipment requirements. Equipment requirement document will be prepared. The 28VDC Battery will comply with the limitations and regulations of the MIL-STD-704F standard. The system functions of the 28VDC battery are defined as in Table 6. 28VDC Battery shall have two different electrical connections.One is employed for power delivery during charging and discharging operations that is connected to A/C 28VDC BUS. 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-0006 Interface Control Document. Battery top level block diagram is shown in Figure 3. 
Figure 3  Battery Top Level Diagram
 
5.1.1	System Functions Allocated to Electrical Hardware and Software
System level and high-level hardware and software functions for 28VDC 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 Voltages	Hardware	Module	Y
Read Module Voltages	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 Battery Temperatures	Hardware	Module	Y
Read Battery Temperatures 	Software	BMB	Y
Sense Module Current	Hardware	BMB	Y
Read Module Current 	Software	BMB	Y
Implement Analog Overtemperature 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 Battery Temperatures	Hardware	Module	Y
Read Battery Temperatures 	Software	BMB	Y
Sense Module Current	Hardware	Module	Y
Read Module Current	Software	BMB	Y
Implement Analog Overtemperature 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 Circuit	Software	BMB	N
Provide Input Signals to Discharge Switching Circuit	Hardware	Module	N
Control Discharge Switching Elements	Hardware	Module	Y
Perform Thermal Management	 	 	 
Sense Battery Temperatures	Hardware	Module	Y
Read Battery 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 Overtemperature 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 Battery Temperatures	Hardware	Module	Y
Sense Module Current	Hardware	Module	Y
Sense Cell Voltage	Hardware	Module	Y
Read Battery 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 Analog Circuit	Software	BMB	N
Provide SOC Analog Signals to Communication Connector 	Hardware	BMB	N
Provide Battery Temperature Analog Output Signal	 	 	 
Sense Temperature	Hardware	-	N
Provide Temperature Analog 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 Discrete Output Signal to Communication Connector	Hardware	BMB	N
Provide Service Warning	 	 	 
Prepare Battery Status Data	Software	BMB	Y
Provide Service Signal in Logic Level to Discrete Circuit	Software	BMB	N
Provide Service Discrete Outrput Signal to Communication Connector	Hardware	BMB	N
Limit Charge Current	 	 	 
Sense Module Current	Hardware	Module	Y
Read Module Currents	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 Battery Current	Hardware	BMB	Y
Read Battery 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 System Description Document “BL-SD-001-0006”.
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 28VDC Bus. 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-0006 Interface Control Document.
5.1.2.2	Internal Interfaces
The software must have various interfaces to perform the functions allocated to it. In order for the software to perform the functions assigned to it, it must have various interfaces. The inputs and outputs that the software gives to the hardware are specified in the software-hardware interface. Figure 4 clearly shows the software-hardware interfaces.
Analog Interfaces:
•	Analog output
o	Analog SOC: It expresses the remaining capacity in the battery as an analog value.
Digital interfaces:
•	Digital inputs:
o	Charge Detect: GPIO input signal to detect that the charger is connected to the battery.
o	Module INA Alert: GPIO signal to detect current alert signal in modules.
o	Module Detect: It is the GPIO signal used to detect when the modules are active.
o	Load Detect: GPIO input signal to detect the presence of load at the battery output.
•	Digital Outputs:
o	All Fet Off: GPIO signal to directly turn the battery output on and off.
o	Module Enable: GPIO signal to enable module powers.
o	Pre Fet Off: GPIO signal used to control pre-discharge and pre-charge simultaneously in all 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	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.
o	Low Capacity: Indicates that the battery capacity is below the configured capacity value.
o	Engine Start: Indicates whether the battery's available energy is sufficient to fully complete the engine starting process.
•	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	I2C Multiplexer: It enables communication with more modules by duplicating the limited number of MCU I2C communication lines.
o	Multi channel ADC: It detects the heater temperature and current, the current and temperature of the limiting circuits, and the temperature of the switching elements in the modules and transmits them to the MCU.
o	Limiter DAC: To limit the module currents, it generates an analog reference voltage according to the current limiting parameters sent by the software.
o	Modul Current/Voltage Monitoring: It detects the total stack voltage of the module cells and the module current and transmits it to the MCU.
o	Modul Monitorıng: It detects each cell string voltage and cell temperatures in the modules and transmits them to the MCU.
o	I/O Expender Control: It is used to charge, discharge, and turn off the power of heater switching elements, limiting switching elements and moldules in modules.
o	I/O Expender Check: Provides status information to the software to control the status of charge-discharge, heater, limiter and pedischarge switching elements and analog protections in the modules.
o	Led Driver: It reports the active status of the battery, service status, fault status, heater status and battery SOC status to the Battery Status Indicator.
o	Batery Current/Volatge Monitoring: It detects the battery pack voltage and the total charge-discharge current of the battery and transmits it to the MCU.
•	ARINC 429
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 5) 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 5: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-0004 KAAN Preliminary System Safety Assessment.
5.1.5	High-Level Hardware Functions and Contribution to Potential Failures 
High-level hardware potential failures of battery functions are briefly given in Table 7. Only branch level functions DAL A and DAL B are included in the table. Loss of function is explained with a short example. DAL levels of all hardware level functions will be determined as a result of safety analysis.


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 CUV protections 	B
5	Loss of Analog Overtemperature protections 	B
6	Loss of OTC protections	B
7	Loss of OTD protections	B
8	Loss of MUV protections	B
9	Loss of SCD protections 	B
10	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 28VDC Battery.
6.1	Hardware Architecture
28VDC battery consists of 6 modules, each containing a control board, a monitor board, cells, a heater and thermal sensors, and the current sense board together with the battery management board. Each module, consisting of four cells connected in parallel, provides 10Ah capacity. The entire battery, comprised of 6 such modules, offers a total capacity of 60Ah. 60Ah 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-0006 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 192 cells.
The modular design offers redundancy and enhances safety. Each module incorporates a control board, a monitor, 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 6 illustrates the preliminary design architecture of the 28VDC battery system. 

Figure 6 Pre-design Architecture of 28VDC Battery
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 analog signals to the analog protection circuit and to the BMB using I2C communication. The data processed on the BMB board and the signal output of the analog protection circuit are transferred to the charge-discharge logic circuit of the monitor board. The charge-discharge logic circuit will be designed considering safety criteria. The output signal of the logic circuit will be transferred to the control board and will control the switching elements on the control board. In addition, the monitor board will perform the cell balancing process to correct the imbalance between the cells.
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 28VDC Bus 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. Figure 3 clarifies the modular design concept for 28VDC battery. 
6.1.1	Battery Managament Board (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 7. 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 ±5VDC 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	Analog SOC
It will convert the logic level SOC value from the MCU to a voltage range of 0VDC to +5VDC. The converted SOC voltage value will be filtered and transmitted to the communication connector. Simple COTS IC will be used for Analog 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. It will provide BMB's battery SCD protection function, precise current reading for SOC calculation and shutdown of all modules in case of short circuit.
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.1.13	Fet Control
It is used by the MCU to directly control the fets of all modules simultaneously. It consists of simple passive elements. It provides isolated control with modules.
6.1.1.14	Charge – Load Detect
In case the battery enters protection, it needs to detect a charge or load to exit protection. It is used to detect whether a charge is connected to the battery power output or whether a load is connected. It consists of simple passive elements.
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 Modules 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. Battery 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 analog 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 8.

 
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 Analog Protection
Analog 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. 
Analog protections are:
•	Analog COV protection.
•	Analog Overtemperature (AOT) protection.
•	Analog 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. Analog 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 analog protection circuit provides analog protection for heater overheating according to the signal coming from the heater control circuit from the control boards in each module.
All analog 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 module monitoring will detect the temperature sensor in the battery and the string cell voltages and transmit them to the MCU. For monitoring, it will detect the voltage of each cell and the cell temperatures of each module and transmit them to the MCU via I2C communication. It will not perform any operation other than monitoring. There will be a COTS IC for monitoring.
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 analog 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 / 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 converter circuit to the COTS Ics on the control board.
6.1.2.1.9	Analog Control
The analog 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. Analog 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 one simple task. This task is:
 • When a large amount of capacitive load is connected to the battery outputs, it will prevent the capacitive load from drawing instantaneous high current. 
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 task. This task is:
• 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. This function will only be used by Aspilsan ENERJİ. 
6.1.2.1.12	Low Voltage Detect
When the engine is started, it may draw very high current from the battery for a short time. High current draw can momentarily lower the battery voltage. This instantaneously falling voltage may disrupt the electrical power of the BMB and cause the MCU and ARINC 429 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 analog 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 analog signal isolation circuit. Analog 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 analog 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 Analog Protection 
According to the DAL levels obtained according to the FTA security analysis results of the system level functions, secondary level analog protections for the redundant structure have been added to the required system level functions. Second Analog Protection hardware consists of COTS simple ICs. Second Analog Protection hardware includes the following protections:
•	Modular SCD protection.
•	Modular MUV protection.
The second analog protection hardware also includes sensors that detect the temperatures of the module switching elements.The second analog 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 analog 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
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	Analog 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 analog 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 analyse 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 28VDC 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 28VDC 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-0004.
 
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 charging, it does not enter the discharge software protection. Discharge. 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.
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.
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 analog COV threshold. The generated error signal is transmitted to the charging logic circuit of the module.
Sense Modul Current	The second analog 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 Battery 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 Analog Overtemperature Protection	The first analog protection circuit in the modules generates an error signal when it detects a temperature above the analog 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 analog 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 analog protection circuit in the modules generates a fault signal when it detects a module discharge current above the analog 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 analog 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 Analog Signals to Communication Connector 	The signals at the voltage levels of 0VDC and +5VDC coming from the analog 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 value is transmitted to BMB.
Provide Temperature Analog 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 Discrete Output Signal to Communication Connector	It isolates the Fault warning signal coming from the MCU and transmits it to the communication connector.
Provide Service Discrete Output 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.




 
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. 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 analog 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 analog 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 analog 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 analog 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 board 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 board 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	Analog 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 VDC required for the control board.
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 analog 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 analog 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 analog 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 analog 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 analog 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 analog voltage and temperature value it detects to the MCU. It simply compares the parameter value determined with the value it detects as analog 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 board and transmits them to the MCU. It also compares for analog 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 analog 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	Analog 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 28VDC battery.
6.7	Hardware Safety, Redundancy and Partitioning
28VDC Battery has DAL B 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-0004.
28VDC 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, ACOV, MUV, OCD, SCD functions in battery are inherently functional redundant. COV and MOV protections protect the circuit from overvoltage conditions, while CUV and MUV protections protect against voltage sags. Although these types of protection are not completely redundant, they complement each other and increase the overall reliability of the system. If one protection circuit fails, the others can help prevent damage to the system. This provides partial redundancy for the system and contributes to fail-safe behavior. AOT temperature protection will provide redundancy to the OTC and OTD protections provided by the software, both during charging and discharging. Even if the MCU is gone, these protections can be provided as hardware in isolation. 
6.8	Single Event Upset Planning
SEU occurs when high-energy particles (e.g., cosmic rays or radiation) strike an electronic device, temporarily disrupting the circuitry. This can lead to a single-bit error or unexpected behaviour in the device's memory or logic circuits. SEU does not cause permanent physical damage but results in a temporary malfunction.
6.8.1	SEU Analysis
ECC is a critical technique used to detect and correct memory errors, ensuring data integrity against SEUs (Single Event Upsets) by adding extra bits to the data stored in memory. These extra bits enable the system to detect and correct single-bit errors and, in some cases, detect multi-bit errors. This benefit of ECC makes it particularly effective against SEUs.
In the TMS320F28377S processor, ECC is integrated into both flash memory and SRAM. When data is written to memory, ECC generates a code that represents the state of the data. This code is stored alongside the data itself. When the data is later read from memory, ECC checks the data against the stored code. If a bit has been flipped due to an SEU, ECC will detect the discrepancy and correct the error before the data is used by the processor.
Additionally, ECC not only corrects errors but also provides diagnostic information that can be used to monitor the system's health over time.

7	CERTIFICATION CONSIDERATIONS
7.1	Certification Basis 
28VDC Battery development will be predicted based on DAL B according to RTCA/DO-254 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-0004 KAAN Preliminary System Safety Assessment. The analysis and results are shared in the RP-PSSA-001-0004 KAAN Preliminary System Safety Assessment. The highest hardware level is B. The hardware is analysed part by part in the RP-PSSA-001-0004 KAAN Preliminary System Safety Assessment.
7.3	 Hardware Means of Compliance
The KAAN 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 security 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-0002 Design Organisation Interface Document.
8.2	Processes
The PL-HDP-001-0001 KAAN Hardware Design Plan describes the life-cycle processes in detail. In addition, The PL-HVVP-001-0001 KAAN Hardware Validation Verification Plan describes the validation and verification processes in detail. What follows is a brief summary.
The life cycle processes according to DO-254 Section 3 are used. 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-HDP-001-0001 KAAN 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.
•	Implementation: It is implemented in accordance with the safety and quality requirements of detailed design.
•	Means of providing feedback and interaction: The PL-HDP-001-0001 KAAN 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.
•	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	Design 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-HDP-001-0001 KAAN 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-0001 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-0004 Preliminary Safety Assessment Report 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 DO 254, simple COTS microprocessor will be used in this product. Detailed information about this COTS is given in document PL-PSA-001-0001. The process specified in the PL-ECMP-001-0001 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 hardware 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-0004 Preliminary System Safety Assessment document.
10.8	Tool Assessment and Qualification
The tools to be used for hardware design will be qualified according to the Figure 10. Outputs of all tools will be assessed independently. No tool will be used for battery verification.
 
Figure 10 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 boards, 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)	Analog 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-0001. 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 analog 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
The contracts has been signed until the end of PDOR. Only SOI-1 will be done in this contracts. The title will be updated when the contracts is renewed as Phase I Stage II.
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: AMC-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  PL-ECMP-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.3
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.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.3

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 DO-254 objectives is shown in defined section. Design lifecycle processes are described in detail in the HDP.
" Yukarıdaki döküman metinen göre aşağıdakı checklistleri  cevpla."

"Item #	SOI #1 Evaluation Activity/Question	Related DO-254 objective(s)
1.1	Review all plans (PHAC, HCMP, HPAP, HDP, HVP, tool qualification plans, etc.) and standards. Based on your review of all the plans, consider the following questions:	 
1.1.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	4.1(1,2,3,4)

7.1(1,2,3)
1.1.2	Are plans, standards, design and verification environments cited complete, clear, and consistent (e.g., can the design and verification engineers follow them)?	4.1(1,2,3)
1.1.3	Do the plans and standards address the content as specified in DO-254 section 10 (i.e., sections 10.1.1 through 10.1.6)?

Note: The plans and standards are not required to be packaged as identified in 10.1.1 through 10.1.6; however, the items specified in 10.1.1 through 10.1.6 should be documented somewhere in the plans and standards.	4.1(1,2,3,4)
1.1.4	Do the plans and standards address the hardware change process and procedures modifying the hardware and tools (if tools are used)?	4.1(1)

7.1(3)
1.1.5	Are all hardware tools identified in the plans and does the tool assessment provide rationale included for why each does or does not need to be qualified?	4.1(1,2,3,4)
1.1.6	Are the inputs, activities, transition criteria, and outputs specified for each process (including identification of sequencing and feedback mechanisms)?	4.1(1)
1.1.7	Are the proposed design methods defined and explained (including identification and rationale of the proposed validation and verification methods)?	4.1(1,4)
1.1.8	Is there evidence that appropriate planning process activities have been adequately performed to meet the planning process objectives will be met? (Refer to section 4.2 of DO-254)	4.1(1,2,3,4)
1.1.9	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)?	All objectives
1.1.10	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?	4.1(1,3)
1.1.11	Are the interfaces and communication channels with the system safety assessment process addressed in the plans and well defined? Evaluate the flow down of safety-related requirements and safety objectives from the system safety assessment (SSA) process to the hardware processes, and the feedback of derived requirements to the SSA process for evaluation.	4.1(1,3)
1.1.12	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.	4.1(1,3)
1.1.13	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?	4.1(4)
1.1.14	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?	4.1(4)
1.1.15	Have all foreign certification issues (e.g., certification review items, certification action items, review findings/issues/actions, etc.) been addressed (if a joint certification or validation project)? Additionally, do the plans and standards address how the foreign certification authority issues and concerns will be addressed?	4.1(4)
1.1.16	Are the means of compliance of the hardware design assurance objectives defined and are they commensurate with the design assurance level(s)?	4.1(4)
1.2	Determine if additional considerations defined in Section 11 of DO-254 have been documented and addressed in the plans. Consider the following questions:	 
1.2.1	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?	4.1(1,2,3,4)
1.2.2	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?	4.1(1,2,3,4)
1.2.3	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?	4.1(1,2,3,4)
1.2.4	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.	4.1(1,2,3,4)
1.2.5	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/	4.1(1,2,3,4)
1.3	Review PHAC and consider the following questions:	 
1.3.1	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.	4.1(1,2,3,4)
1.3.2	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?	
4.1(1,2,3,4)

7.1(1,2,3)
1.3.3	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.	4.1(4)
1.3.4	 Does the PHAC address the additional and applicable considerations described in Appendix B of DO-254?	4.1(4)
1.3.5	Does the PHAC define independence and describe the method for independence required for Level A and B hardware?	4.1(4)
1.4	Review HDP and consider the following questions:	 
1.4.1	If the HDP is followed, will the applicable DO-254 design processes objectives be met?	4.1(1)
5.1.1(1,2,3)
5.2.1(1,2,3)
5.3.1(1,2,3)
5.4.1(1,2,3)
5.5.1(1,2,3)
1.4.2	Does the HDP adequately address the proposed contents described in DO-254, Section 10.1.2? If not, are the contents included in another plan?	4.1(1,2,3,4)
1.4.3	Are the hardware design processes defined in sufficient detail to ensure proper implementation of the hardware life cycle processes and model proposed for the project? Are transition criteria clear and enforceable?	4.1(1)
1.4.4	Will applicable aspects of the HDP, development environment, standards and processes be conveyed to any sub-tier suppliers of components of the system and subcontractors to ensure their compliance to the approved plans, standards, and procedures?	4.1(1,2,3)
1.4.5	Has the hardware development environment been adequately defined (e.g., documentation tools, requirements definition and capture tools, traceability tools, design tools (including architecture, derived requirements definition and capture tools, HDL coding tools, integration tools, development host computer environment, tools to ensure protection of baselined hardware life cycle data such as configuration management and control tools, access privileges, etc.)? Additionally:
• Are tool users’ guides, restrictions, and limitations available and known by the hardware developers using them?
• Do any of the tools support enforcement of the hardware description languages (HDL) standards, transition criteria, data baselining and approval process, etc.? For example: (1) does the HDL code editor tool or compiler enforces any coding rules, restrictions, or limitations? (2) does the document control (CM system) enforce access privileges to data and ensure no unauthorized changes to baselined data?	4.1(2,3)
1.4.6	What kind of synthesis tool is being proposed? Does the applicant have experience with the synthesis tool? Have the synthesis tool’s options and optimization been identified? Have the errata sheets, vendor problem notices bulletins, or vendor problem reports for the synthesis tool been reviewed and analyzed for safety impact on the operation of the tool? If safety impacts have been identified, then have the mitigations been implemented and documented for the synthesis tool?

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

Note: Some HDL constructs may produce non-deterministic results and therefore may not meet the objectives of DO-254.	4.1(2)
1.5	Review the HCMP and consider the following questions:	 
1.5.1	If the HCMP is followed, will the applicable DO-254 configuration management objectives be satisfied?	4.1(1)

7.1(1,2,3)
1.5.2	Does the HCMP adequately address the proposed contents described in DO-254, Section 10.1.5?	4.1(1,2,3,4)
1.5.3	Will applicable aspects of the HCMP, environment, tools, training and procedures be conveyed to any sub-tier suppliers of components of the system and subcontractors to ensure their compliance to the approved plans, standards and procedures?	4.1(1,2,3)
1.6	Review the HPAP and consider the following questions:	 
1.6.1	If the HPAP is followed, will the process assurance objectives be satisfied?	4.1(1)

8.1(1,2,3)
1.6.2	Does the HPAP adequately address the proposed contents described in DO-254, Section 10.1.6? If not, are the contents included in another plan?	4.1(1,2,3)
1.6.3	Is hardware PA independent from the development organization to a sufficient degree to ensure that PA has the autonomy and authority to ensure PA audit findings, actions, and deficiencies will be corrected?	8.1(1,2,3)
1.6.4	Are there any deviations proposed for this project from the PA plans and procedures? If so, are those deviations identified and justified?	7.1(3)

8.1(3)
1.6.5	Are the transition criteria, interrelationships, and sequences among process properly and adequately defined, and are they capable of being audited to ensure process compliance?	4.1(1)

8.1(1)
1.6.6	Are there defined procedures for how PA audit findings, actions, and observed deficiencies will be corrected for the project?	4.1(1)
1.6.7	Is the PA findings process a separate process or does it use different tools for issues resolution than the development organization (i.e., how are the PA and development team problems reported)?	4.1(1)
1.6.8	Are the criteria for PA involvement (sampling, attending reviews, evaluation, conducting process compliance audits, witnessing tests, “conforming” environments, etc.) defined to ensure that life cycle objectives are met?

Note: Criteria for involvement may be dependent on the hardware level or novelty of the product being developed.	4.1(1)
1.6.9	Has a person or organization responsible for each documented PA process and activity been identified?	8.1(1,2,3)
1.6.10	Will applicable aspects of the HPAP, environment, tools, training, and procedures be conveyed to any sub-tier suppliers of components of the system and subcontractors to ensure their compliance to the approved plans, standards, and procedures?	4.1(1,2,3)
1.7	Review the HVP (Validation/Verification) and consider the following questions:	 
1.7.1	If HVP is followed, will DO-254 validation and verification objectives be met?	4.1(1)
6.1.1(1,2,3)
6.2.1(1,2,3)
1.7.2	Does the HVP adequately address the proposed contents described in DO-254, Section 10.1.3 & 10.1.4? If not, are the contents included in another plan?	4.1(1,2,3)
1.7.3	 Will applicable aspects of the HVP plan, environment, tools, training and procedures be conveyed to any sub-tier suppliers of components of the system and subcontractors to ensure their compliance to the approved plans, standards, and procedures?	4.1(1,2,3)
1.7.4	Does the HVP describe how independence will be achieved, when required?	4.1(1)
1.7.5	Does the HVP describe the verification method used for each hardware verification activity? Specifically:
• Are methods, checklists, tools and procedures described for conducting reviews of hardware requirements, design, coding, and integration?
• Are methods, checklists, tools and procedures described for conducting analyses of traceability, change impact, timing, verification coverage, normal range coverage, robustness test coverage, etc.?
Note: Robustness testing does not appear as an objective for DO-254, but its application has shown to be effective for other domains (e.g., software).
• Are methods, checklists, tools and procedures described for conducting reviews of test plans, test procedures, test cases, and test results?
• Are methods, checklists, tools and procedures described for conducting testing of hardware requirements, hardware derived requirements, hardware integration, hardware-software integration, normal range, and robustness?
• If hardware verification test credit will be claimed for testing conducted on system benches, laboratory, integrated system facilities, do the plans and procedures describe how those activities will be conducted and hardware test results and coverage analyses documented?
• Is there a well-defined process and procedure for ensuring that deficiencies detected during the testing process will be conveyed to and corrected by the hardware design process and team?	4.1(1,2,3)
1.7.6	Does the HVP adequately describe the verification environment (e.g., tools, test equipment, etc.)? Consider the following questions:
• Are there any automated tools? If so, do any of the tools need to be qualified?
• Is there any overlap between various kinds of testing (e.g., overlap of system and hardware requirements-based testing)?
• Is the division of the testing task between suppliers and sub-contract suppliers adequately addressed and controlled?	4.1(1,2,3)
1.7.7	Are verification plans, including test plans, and procedures conveyed to suppliers and sub-contractors to ensure their activities and results will comply with the approved plans and procedures?	4.1(1,2,3)
1.7.8	Does the HVP describe methods for test case selection? Does the HVP specify how each requirement will be tested (e.g., hardware component test, board level/hardware integration test, hardware/software integration test)?	4.1(1,2,3)
1.7.9	Does the HVP or procedures specify who is allowed to perform verification tasks?	4.1(1)
1.7.10	If verification tools are used, has the tool assessment process as described in section 11.4 of DO-254 been followed?

Note: See section 11.4 of DO-254 for more information on tool assessment and qualification process.	4.1(1,3)
1.8	Review the hardware design standards and consider the following questions:	 
1.8.1	Are the hardware design standards (Requirements Standards, Hardware Design Standards, Validation and Verification Standards, and Hardware Archive Standards) identified and well defined?	4.1(2)
1.8.2	Are the hardware design standards consistent with the plans and do they support implementation of the plans?	4.1(2)
1.8.3	Will the hardware design standards support the proposed hardware level(s) and hardware’s compliance with DO-254 objectives?	4.1(2,4)
1.8.4	Have standards been verified for each defined hardware life cycle process? Are the standards adequate to support the hardware level?	4.1(1,2,3,4)
1.8.5	Have standards been described in detail to support the planning process objectives (see sections 10.2.1, 10.2.2, 10.2.3 and 10.2.4)?	4.1(1,2,3,4)
1.8.6	If HDL or another hardware design language is used, have coding standards been verified to ensure that any constructs are not permitted which would invalidate the assumptions about the safety levels (e.g., non-determinism)?	4.1(2)
1.8.7	Have the hardware design standards been verified to ensure that there are limitations, prohibitions, and constraints to not permit the use of design and code features that are not deterministic and not verifiable?	4.1(2)
1.8.8	What HDL is being used?
• Does the applicant have experience with the language?
• Does the HDL have any features or capabilities that may be difficult to verify? Has the applicant or developer imposed any prohibitions or restrictions on the use of these features in the coding standards and/or review checklists? Does the applicant/developer have plans and procedures established for how these features will be verified?
• What features of the HDL support or hinder real-time implementation and verification?
• Are any HDL problems documented and addressed?
• Has a safe sub-set of the HDL been selected? How will it be verified that that safe sub-set was adhered to (e.g., code reviews, checklists, testing, etc.)?
• What are common errors of the HDL? Do coding standards protect against these errors?	4.1(1,2,3)
"