Chapter 4 Reuse Of IMA Components.
4-1. Reuse of an Accepted IMA Component.
a. If a previously accepted IMA component is unchanged, its intended reuse meets the limitations in the IMA Component Acceptance Letter, and the FAA engineer for the certification program in which the IMA component is being reused does not have any concerns, you may reuse that component without need for additional FAA review of the originally accepted IMA component compliance data.
b. If you are an IMA developer/system integrator or applicant proposing to reuse a previously accepted IMA component, you should ensure and document that you identified no safety, installation, operational, functional, or performance concerns with the subsequent use of that component.
c. Although the intent of IMA Component Acceptance Letters is to document our acceptance of the compliance data for an IMA component, the existence of such a letter does not prevent us, on a new or concurrent TC/STC/ATC/ASTC program, from requesting to examine the compliance data associated with the accepted IMA component if we have questions or concerns. We will first try to address any open questions without resorting to re-examination of the previously accepted compliance data. However, if we have specific concerns that cannot be answered by any other means, we may ask you to provide some of the previously accepted data. Only compliance data specific to the identified issue or concern should need to be re-examined. If the initial IMA Component Acceptance Letter was done correctly and all necessary compliance data was included in the IMA Component Acceptance Letter, we should not need to resort to re-examination of previously accepted compliance data.
d. RTCA/DO-297, paragraph 4.7.1, states that future reuse of any component should be planned during the initial development of that component and documented in the appropriate certification planning document. An IMA component not initially developed for future reuse and lacking a signed Acceptance Letter should be treated as a newly developed component.
4-2. What Can Be Reused.
a. RTCA/DO-297, subsection 4.7 states that reuse of a previously accepted component should be limited to modules (see Task 1 in RTCA/DO-297, subsection 4.2) and applications (Task 2, subsection 4.3). We do not allow reuse of previously accepted data at the IMA system level (Task 3, subsection 4.4) or IMA installation level (Task 4, subsection 4.5).
b. RTCA/DO-297, subsection 4.7 limits reuse of the types of data for Tasks 1 and 2 to the following technical subjects:
(1) Airborne software compliance to RTCA/DO-178B. See RTCA/DO-297, paragraph
4.7.2 and paragraph 4-4 below.
(2) CEH component compliance to RTCA/DO-254. See RTCA/DO-297, paragraph
4.7.3 and paragraph 4-5 below.
(3) EQT compliance to RTCA/DO-160F. See RTCA/DO-297, paragraph 4.7.4 and to paragraph 4-7 below.
c. In addition to those three technical data types, this AC identifies comprehensive testing of SEH as another data type for which acceptance data can readily be developed, packaged, and accepted for future reuse. Reuse of compliance data for SEH is not covered in RTCA/DO-297.
(1) RTCA/DO-254, subsection 1.6, provides the following definition:
Simple Hardware Item - Item with a comprehensive combination of deterministic tests and analyses appropriate to the design assurance level that ensures correct functional performance under all foreseeable operating conditions, with no anomalous behavior.
(2) AC 20-152, RTCA, Inc., Document RTCA/DO-254, Design Assurance Guidance for Airborne Electronic Hardware, says that applicants should apply RTCA/DO-254 to custom micro-coded components, which are a subset of "hardware items." This is AC 20-152's definition:
Custom micro-coded component - A component that includes application specific integrated circuits (ASIC), programmable logic devices (PLD), field programmable gate arrays (FPGA) and other similar electronic components used in the design of aircraft systems and equipment.
(3) FAA Order 8110.105, paragraph 5-1, explains that SEH is a custom microcoded component that satisfies the definition a simple hardware item of RTCA/DO-254.
The design of an SEH device can be shown to be correct and complete by comprehensive testing and analysis without a detailed development assurance process. Ask your FAA ACO for more information regarding definitions and explanations of CEH, SEH, hardware items, and custom micro-coded devices. See RTCA/DO-254, subsection 1.6 for more information on simple hardware items.
4-3. Reuse of Other Types of Compliance Data.
a. If you are an IMA component developer intending to develop any data for future reuse beyond those listed in 4-2.b and 4-2.c, you should include this intent in the appropriate certification planning document. Work closely with us, the IMA developer/system integrator, and applicant at the beginning of the component development program to ensure that future reuse of this data is feasible, and all parties agree on what is required to ensure the success of any future reuse. We are not required to accept a proposal for future reuse of data beyond those listed in 4-2.b and 4-2.c, but we will consider your proposal.
b. Any compliance data beyond those data types listed in paragraphs 4-2.b and 4-2.c. that you propose for inclusion in an IMA Component Acceptance Letter should fall within Tasks 1 and 2, per paragraph 4-2 above.
c. The IMA component requirements for the additional compliance data types should be documented in an appropriate certification document and referenced in either the IMA Component Acceptance Cover Letter or the IMA Component Acceptance Letter data sheet.
4-4. Reuse of Previously Accepted Software-Only or Hardware Component Containing Airborne Software.
a. RTCA/DO-297, paragraph 4.7.2, addresses reuse of a software module or application.
However, as stated in RTCA/DO-297, paragraph 4.7.5, this guidance should also be followed for IMA hardware components that contain airborne software.
b. In addition to the guidance for reuse of a previously accepted component containing airborne software provided by RTCA/DO-297, the guidance for the reuse of airborne software contained in AC 20-148, Reusable Software Components, should also be used in its entirety, with the exception of Chapter 9 which addresses the Reusable Software Component (RSC) Acceptance Letter. AC 20-148 contains more detail than RTCA/DO-297 about developing airborne software for reuse, and reusing that software in another project. AC 20-148 specifies the roles and responsibilities of all parties, the processes to be used, how the data should be developed when future reuse is intended, and what data should be supplied by the software developer to the integrator of the software or to the applicant.
c. RTCA/DO-297, paragraph 4.7.2 states that the prerequisites for reusing previously accepted software is that the software should be hosted on the "same target hardware" and is "used in the same way operationally" for the earlier accepted application and the intended reuse application. Given the rapid change in technology employed in today's IMA systems as well as the rapid rate of hardware parts obsolescence, it's likely that the intended platform that is to host the reused software component will not include the same target hardware that initially hosted the accepted software. The target hardware may include a microprocessor from the same family as that of the previous target hardware. However, coming from the same family of microprocessors does not automatically qualify as "the same target hardware." If an IMA developer/system integrator or applicant wants to reuse a previously accepted IMA component that contains sottware, but that software will be hosted on non-identical target hardware, the applicant should ensure compliance with all RTCA/DO-178B and RTCA/DO-297 objectives and document how they intend on showing that compliance.
4-5. Reuse of CEH or Hardware Component Containing CEH.
a. AC 20-152, paragraph 2.c states that RTCA/DO-254 applies to complex custom microcoded components with hardware design assurance levels A, B, and C. See paragraph 4-2.c (2) for definition of custom micro-coded components. Accordingly, we restrict granting IMA Component Acceptance Letters (per RTCA/DO-297, paragraph 4.7.3) to RTCA/DO-254 17
complex custom micro-coded components - that is, to CEH and not commercial-off-the-shelf (COTS) hardware devices.
b. Your ACO will use FAA Order 8110.105 for definitions and additional information on using RTCA/DO-254 as an acceptable means of compliance.
c. Currently, there is no guidance for CEH that defines a detailed acceptable means of compliance similar to that provided by AC 20-148 for an RSC. However, because of the many similarities between the processes in RTCA/DO-178B for airborne software and those in RTCA/DO-254 for airborne electronic hardware, adapt the paragraphs of AC 20-148 listed below to CEH. Use these paragraphs of AC 20-148 when negotiating an agreement between yourself and us on reusing CEH components:
(1) Paragraph 4 - General Guidelines for Getting the FAA to Accept an RSC.
(2) Paragraph 5 - Guidelines for the RSC Developer.
(3) Paragraph 6 - Data the RSC Developer Must Supply to the RSC Integrator or Applicant.
(4) Paragraph 7 - Guidelines for the Integrator and Applicant Using the RSC.
(5) Paragraph 8 - Expectations from FAA on First Use of an RSC.
(6) Paragraph 10 - Expectations from FAA on the Subsequent Use of an Accepted RSC.
4-6. Reuse Of SEH or Hardware Component Containing SEH. As with CEH, there's no current guidance on reusing SEH compliance data. Consult the same paragraphs listed in paragraph 4-5 above when negotiating with us on adapting and using these paragraphs for SEH components. Your ACO will use FAA Order 8110.105 for information on SEH and our expectations regarding comprehensive testing of SEH components.
4-7. Reuse of EQT Data.
a. RTCA/DO-160F, Section 1, stresses the importance of selecting the right environmental conditions and test procedures for equipment under test. A phrase used throughout RTCA/DO- 160F is, "determine compliance with applicable equipment performance standards." If you are the tester responsible for EQT, it is up to you to determine the specific test configuration and requirements appropriate for the equipment under test. There are many aspects of environmental testing - vibration levels, temperature, altitude, orientation of equipment, electrical connectors, electrical grounding schemes, and electrical wire lengths - specific to the aircraft in which the equipment will be installed. The qualification test plan for the equipment under test should properly define all variable test parameters.
b. RTCA/DO-297, paragraph 5.2.6 stresses the flexibility and reconfigurable nature of modern IMA systems. That is, although the basic architecture of an IMA system is set and will 18
not change, each IMA system can be tailored specifically for the aircraft or engine in which it is installed. This is true for the functionality provided by the IMA system as well as for the environmental conditions to which it is subjected - for example, vibration levels for installation in a rotorcraft versus a fixed wing aircraft. This flexibility, while beneficial in many respects, introduces complications when you attempt to develop reusable EQT data per RTCA/DO-297, paragraph 4.7.4.
c. A company asking us for an IMA Component Acceptance Letter for an IMA component being developed for future reuse should ensure that the data package of this component clearly identifies all variables and parameters used during EQT. The IMA developer/system integrator intent on reusing a previously accepted component which includes EQT data should ensure that all aspects of that testing are appropriate for the aircraft or engine in which it will be installed. If any testing variable or parameter used during the component's initial acceptance is not identical to what is required for the intended reuse, then the integrator of that previously accepted component should document those differences and justify why they are acceptable for the new intended installation. If there is not adequate justification for any difference between the original acceptance and the intended reuse, then the IMA developer/system integrator or applicant should re-test that aspect of the EQT, using the appropriate values and test configurations.
4-8. Data the Component Developer Owes to the IMA Developer/System Integrator or Applicant.
a. The developer of a previously accepted IMA component should supply the IMA developer/system integrator and/or applicant who is reusing the component with many different types of data. This ensures that the IMA developer/system integrator and applicant can fully satisfy the objectives of RTCA/DO-297, subsection 4.7 and Annex A. The data required by the IMA developer/system integrator and applicant are likely to exceed that included in the IMA Component Acceptance Letter.
b. Instead of providing data directly to another company, the developer of a previously accepted IMA component may choose to use a data/software escrow approach. See AC 20-148, paragraph 6.j(2) for guidance regarding data/software escrow.
e. AC 20-148, paragraph 6 details the data for airborne software that a developer of a previously accepted software component should make available to the IMA developer/system integrator, the applicant, and to us, if we ask. As noted previously, there is no similar guidance for accepted reuse of either RTCA/DO-254 or RTCA/DO-160F compliance data. However, RTCA/DO-297, paragraphs 4.2.3, 4.2.12, 4.3.1, and 4.3.2 document many of the elements required. A developer of a previously accepted IMA component should provide the data required to ensure compliance with RTCA/DO-297, subsection 4.7 and with the objectives of Annex A, either directly or by data escrow, to the IMA developer/system integrator and/or applicant.
4-9. Reuse of a Previously Accepted IMA Component That Was Revised. A previously accepted IMA component that has been revised since its last acceptance should meet the 19
guidance in RTCA/DO-297, subsection 4-5 to be reused in a new or concurrent application. If you want a new IMA Component Acceptance Letter, see paragraph 3-6.
4-10. Reuse of an IMA Component with a Previous TSO Authorization.
a. If the IMA component that has a previous TSO authorization also has been previously issued an IMA Component Acceptance Letter, then the process for reuse of a previously accepted IMA component takes precedence. The applicant and IMA developer/system integrator should use the guidance in section 4 without regard to remainder of this paragraph.
b. If the IMA component that has a previous TSO authorization has not been issued an IMA Component Acceptance Letter, then the following applies:
(1) You should follow all limitations described in the TSO authorization when integrating the component into the IMA system. These limitations should be documented in the appropriate certification planning documents).
(2) The intended usage domain of the TSO authorized IMA component should be identical to the usage domain identified in the TSO authorization. If the intended usage domain is not the same as identified in the TSO authorization, then you should do analysis and/or testing to demonstrate those differences do not affect the use of the IMA component within the intended usage domain.
(3) You should identify all RTCA/DO-178B and RTCA/DO-254 objectives that have only been partially met under the TSO authorization and describe in the appropriate certification planning documents) how full compliance to these objectives will be shown for the integrated IMA system. See AC 20-148, paragraph 5.d(1) for more information.
(4) You should identify all remaining EQT that are required for the aircraft or engine installation that is not covered by the TSO authorization. These remaining EQT should be described in the appropriate certification planning documents). Any EQT results from the TSO authorization that you desire to take credit for at the aircraft or engine installation level should be described in the appropriate certification planning documents). See paragraph 4-7 for more information regarding reuse of EQT data.
(5) Any SEH devices that are within the TSO authorized IMA component should be identified in the appropriate certification planning documents). Compliance to RTCA/DO-254 for SEH devices are not covered by TSO authorizations, unless specifically stated in the TSO.
The guidance of paragraph 4-6 should be used.
Chapter 5 Configuration Management of an IMA System.
5-1. IMA Configuration Management.
a. The applicant is responsible for overall IMA system configuration management.
b. Configuration management of an IMA system installed in an aircraft is critical because the system may contain many hardware components and functional software components, with each component having multiple approved versions or on-aircraft option selections. Some possible combinations of hardware and software versions will not be approved for flight.
c. Configuration management techniques to manage the IMA architecture are necessary to safely accommodate system attributes, such as (but not limited to) the following:
(1) Hosting multiple software applications on a single processor or on multiple, nondedicated processors.
(2) Producing and distributing hardware components without loading specific functional software.
(3) Allowing electronic part numbering for software components, without the need to physically mark hardware elements with the software part number(s).
(4) Allowing the electronic display of TSO identification.
(5) Allowing the field-loading of hardware components with functional software components for efficient maintenance and incorporation of approved design changes.
(6) Allowing the stocking of generic, non-configured hardware components for maintenance purposes. A non-configured hardware component is one that does not already contain the functional software components needed for satisfying an aircraft, engine or system function. These hardware components will be loaded later with field-loadable software. Each generic hardware component may have multiple versions, as components normally undergo updates during their lifecycle. Unless a specific effort is made to purge operator spares of earlier versions of a hardware component, you should assume that every version of a hardware component will exist in service and could be used on an aircraft or engine installation.
(7) Providing the ability to update and maintain IMA system configuration files without corruption.
5-2. Automated, Robust Configuration Management.
a. We strongly recommend a robust, automated configuration management scheme for an IMA system installed on an aircraft. A key feature of an automated configuration management scheme is that the IMA system itself monitors the configuration of either all or a subset of the 21
IMA hardware and software components. When an invalid configuration of the monitored components is detected, it should be annunciated in a way that will not allow the aircraft to be dispatched until the invalid configuration is corrected.
b. A robust, automated configuration management scheme should be able to detect, at a minimum:
(1) Incompatible versions of a software component hosted in a hardware component.
(2) Incompatible versions of multiple copies of a software component hosted in multiple hardware components.
(3) Incompatibilities or uncertified configurations between various systems that are closely coupled, such as autopilot and flight management systems.
(4) Incompatible system configurations with the aircraft model in which it is installed, and
(5) Incompatible option selections.
c. Any loss of function caused by configuration management system protections must be shown to be acceptable through the applicant's aircraft or engine level safety assessment. See § xx. 1309, xx denoting parts 23, 25, 27, or 29 as applicable.
5-3. Non-Automated, Robust Configuration Management. If your configuration management scheme of the IMA system installed on the aircraft or engine is not automated or depends on maintenance personnel to configure the system, either fully or partially, and to determine if the system configuration correct for that specific aircraft or engine, you should explain, in the appropriate certification document, why your configuration management scheme is robust. You should address possible issues with your proposed approach, such as likely maintenance errors that could result in a non-approved IMA contiguration. You should explain the testing and analysis that you plan to do to ensure the process is indeed robust.
5-4. Software Loading Procedures. For IMA systems that allow on-aircraft loading of software, the applicant should provide field-loading procedures that ensure correct software loading, as well as a means to verify that the software load operation was completed successfully and that the correct version of software is now installed.
5-5. Assurance Level of IMA Components Used in Configuration Management. Any IMA system component used in determining the validity and/or safety of an IMA configuration, whether the configuration management system is fully automated or manual, should be developed to the assurance level commensurate with the hazard classification of allowing a nonapproved configuration to be dispatched. This includes automatic configuration monitoring and displaying electronically stored part numbers and versions on a flight deck or maintenance display.
Chapter 6 IMA Recovery Features.
6-1. Restarting Safety Critical IMA Functions. Due to unforeseen circumstances, an IMA function, collection of IMA functions, or an entire IMA cabinet may unexpectedly shut down without the hosting IMA hardware components experiencing a permanent failure. IMA systems must include the ability to restart any hosted function or functions whose continued operation is required by the system or aircraft level safety assessment. See § xx. 1309, xx denoting parts 23, 25, 27, or 29 as applicable.
6-2. Restart Mechanism Implementation.
a. An IMA function or system restart feature included in an IMA system, when feasible, should be initiated automatically when a safety critical loss of function is detected. The IMA design should avoid the need for crew-initiated recovery features.
b. If an automatic recovery feature is not feasible and a crew-initiated - that is, nonautomated - recovery feature is implemented instead, you should put protection mechanisms and operations procedures in place to prevent accidental activation of the recovery feature by the thight crew.
c. The system design should carefully consider how many automatic attempts at restarting failed IMA functions or cabinets should be attempted. Attempting to restart indefinitely when the failed function or cabinet repeatedly shuts itself down may cause increased crew workload or distraction. Repeated failures after restart attempts may indicate that there is a failed IMA resource that should not be restarted. The system restart mechanism design should consider potential causes for restarts and determine the appropriate number of restarts to attempt before declaring the system failed. Factors that influence this architecture are the failure condition(s) associated with loss of IMA functionality, the impact of multiple restarts of a function or functions on interfacing systems, and the functionality remaining from non-IMA systems.
d. The IMA design should not rely on cycling aircraft circuit breakers to restart any IMA system or function. If crew-initiated manual recovery features are used, design a means other than cycling circuit breakers.
e. The applicant should evaluate the effects of automatically and/or manually activating recovery features in both normal and failed conditions for all phases of flight. The applicant should evaluate the effects of loss of functions during manual or automatic restart for all phases of flight.
Chapter 7 Topics Not Covered by RTCA/DO-297.
7-1. Electrical Power For IMA Systems.
a. The applicant and IMA developer/system integrator should design the physical and electrical power architecture of the IMA to support the flight crew's ability to manage smoke or fire events without losing functions whose loss are catastrophic.
b. If are fault circuit breakers (AFCB) are utilized for IMA cabinet or rack circuit protection, they should be specifically qualified for use on aircraft. At the issue date of this AC, the use of AFCB technology in airborne systems is in its infancy. Therefore, until more experience is gained and updated regulatory and/or guidance material is issued for the certification of AFCBs, the FAA may develop a method of compliance Issue Paper for certification programs that use AFCB technology.
c. The IMA cabinet or rack should not be powered with circuit protection features such as software controlled circuit breakers that are controlled by microprocessors hosted in that IMA cabinet or rack. The intent of this guidance is to prevent the complete loss of control of the circuit protection feature(s) of any specific IMA cabinet or rack, or IMA components installed within that cabinet or rack, such that the electrical power input cannot be removed to that cabinet or rack if it fails.
d. The following applies to part 25 transport airplanes only.
(1) Electrical wiring interconnection system (EWIS) components, as defined by § 25.1701, associated with IMA systems must comply with the applicable EWIS requirements of Part 25. See § 25.1701. Refer to Advisory Circular 25.1701-1, Certification of Electrical Wiring Interconnection Systems on Transport Category Airplanes, for specific compliance guidance.
(2) We consider EWIS to be an airplane system. Therefore, EWIS associated with IMA systems required for type certification or by operating rules, including those specifically listed in § 25.1705(b) must be considered as an integral part of that IMA system and must be considered in showing compliance with the applicable requirements for that IMA system. See § 25.1705(b).
(3) Circuit protective devices for the IMA cabinet or rack must comply with the requirements of § 25.1357. See § 25.1357. This includes § 25.1357(t) which requires IMA systems for which the ability to remove or reset power during normal operations is necessary be designed so that circuit breakers are not the primary means to remove or reset system power unless specifically designed for use as a switch.
7-2. Field Loadable Software.
a. Many IMA systems use field loadable software (FLS) as part of the TC/STC/ATC/ASTC installation. FLS is software that can be loaded into the host hardware without removing the equipment from the aircraft installation. FLS might also include software 24
loaded into a line replaceable unit (LRU) or hardware component at a repair station or shop.
FLS can refer to either executable code or data, such as a database. When seeking approval to use FLS, you should consider the following:
(1) FLS should meet the objectives and guidance of RTCA/DO-178B or other acceptable means of compliance, as agreed to between the applicant and your responsible ACO.
(2) The FLS should be loaded on the target computer and hardware configuration that the software was verified on during DO-178B on-target verification testing.
(3) A means must exist to ensure that the FLS is loaded into the proper IMA configuration approved for that aircraft. See § 21.31. See Chapter 5 for more information on configuration management.
(4) If redundant functions of the IMA system are field loadable, the applicant should ensure that they have the same software configuration, unless intermixing of different software configurations is supported by the safety assessment and approved for the aircraft configuration and type design.
(5) The applicant should have a process to assure that the software loaded is the software approved and that it hasn't been corrupted - for example, verification with a cyclic redundancy or other data transfer integrity check. Different data integrity algorithms give different assurances that the data transfer is correct. Ensure that the algorithm used is commensurate with the integrity required for the software level of the data being loaded.
(6) If the applicant proposes more than one medium for loading the FLS, such as a diskette, mass storage device or compact disc, loading from each medium should comply with the guidance in this section.
(7) The applicant should demonstrate that the airborne equipment software part numbers can be verified with onboard equipment, carry-on equipment, an automated configuration management scheme, or other appropriate means.
(8) Loading protection mechanisms should be implemented to inhibit loading FLS during flight. The reliability of these mechanisms should be commensurate with the failure condition associated with the inadvertent loading of software during flight.
Note: Please refer to AC 120-76A, Guidelines for the Certification, Airworthiness, and Operational Approval of Electronic Flight Bag Computing Devices, for guidance that pertains to loadable IMA software components that implement an Electronic Flight Bag function.
b. FLS installation documents should specify the following elements:
(1) Aircraft and hardware applicability and intermixability allowances for redundant systems that load software.
(2) Verification procedures to ensure that the software was correctly loaded into an approved, compatible target computer and memory device(s).
(3) Any post-load verification and/or test procedures required to show compliance to the guidelines specified in this AC.
(4) Actions to take - for example, prohibiting dispatch of aircraft - if there's an unsuccessful load.
(5) Reference to an approved loading procedure.
(6) Maintenance record entry procedures required to document and maintain configuration control.
(7) Reference to the appropriate Aircraft Flight Manual (AFM). Aircraft Flight Manual Supplement (AFMS) or operator's manual. il necessary.
7-3. Electronic Identification Guidance.
a. Identification of software components field-loaded into hardware elements should be implemented by electronic means. Electronic identification markings consist of identifying software components by electronically embedding the identification within softwarc contained in the hardware. rather than on the equipment nameplate.
b. Electronic software part numbers and versions should be verifiable through an electronic query, such as an electronic display. Software part number configuration errors detected by an automated robust IMA configuration management function should be annunciated to the flight crew until appropriate maintenance action is performed.
c. Equipment authorized by TSO must be permanently and legibly marked with specific information. Scc § 45.15(b). The applicant can demonstrate compliance to § 45.15(b) when you provide the information required by an electronic identification query system stored in nonvolatile memory. This approach is commonly called an "electronic TSO nameplate." The electronic identification system should be verifiable onboard the aircraft when the aircraft is on the ground at any geographic location. It must provide the specific information for all applicable TSOs being marked is using the clectronic TSO nameplate as the only means of labeling. See $ 45.15(b).
d. Electronic identification may also provide software and hardware component revision or modification status information and RTCA/DO-178B software levcl. The applicant can use this to demonstrate conformity to type design configuration.
e. Include information identifying the location of each hardware component in the electronic identification. This is necessary because the configuration depends on the specific location of cach hardware component within the cabinet or rack. You can satisfy this 26