Attachment 10f - IBCS - 243-003 HW FMECA Results.docx

UNCLASSIFIED-For Official Use Only IBCS-A243, Rel. 003 01 Nov. 2019

01 Nov. 2019

Integrated Air and Missile Defense (IAMD) Battle Command System (IBCS) IBCS Failure Modes, Effects and Criticality Analysis Hardware (FMECA) Results

Systems Engineering & Integration Document

This material is based upon work supported by the U.S. Army Aviation and Missile Command under Contract No. W31P4Q-08-C-0418.

Integrated Air and Missile Defense (IAMD) Battle Command System (IBCS) Northrop Grumman Mission Systems Missile Defense and Protective Systems Division

213 Wynn Drive

Huntsville, AL 35805

CAGE Code 9F909

Copyright 2020 Northrop Grumman Systems Corporation.

IBCS.DM.025.24 (Jan16)

Copyright 2020 Northrop Grumman Systems Corporation.

UNCLASSIFIED-For Official Use Only

IBCS.DM.025.24 (Jan16)

Integrated Air and Missile Defense (IAMD) Battle Command System (IBCS) Failure Modes, Effects and Criticality Analysis Hardware (FMECA) Results Approval Sheet

SIGNATURES FOR RELEASE:

Jon Tegtmeier, IBCS Reliability Engineering

Date

Andrew Sutinen, IBCS Reliability Engineering Lead

Date

Daiven Harper, Specialty Engineering Manager

Date

Mike Myszka, IBCS SE&IPT Manager

Date

Lori Tatom, IBCS Mission Assurance Manager

Date

Mark Rist, IBCS Program Director

Date

Kristi Fugit, IBCS Configuration/Data Management

Date

Document Type:

e.g., Systems Engineering & Integration

Notes or Comment:

N/A

Northrop Grumman Mission Systems Missile Defense and Protective Systems Division IAMD Battle Command System (IBCS) 213 Wynn Drive Huntsville, Alabama 35805-1928

CHANGE RECORD

Release Number

Date

27 Feb 2019 2 Aug 2019

SOW

SOW

All All DCR-6090, Initial Release DCR-6159, Resubmittal Due to Rejection

01 Nov. 2019

UNCLASSIFIED-For Official Use Only

Copyright 2020 Northrop Grumman Systems Corporation.

ii IBCS.DM.025.24 (Jan16)

Contents

List of Figures

List of Tables

UNCLASSIFIED-For Official Use Only

Introduction This section provides the purpose and scope of the Integrated Air and Missile Defense (IAMD) Battle Command System (IBCS) Failure Modes, Effects and Criticality Analysis (FMECA) Results, as well as application of analysis results, a document overview, updates for the results, and a program overview.

The FMECA supplements the Failure Modes and Effects Analysis (FMEA) and will be incorporated in the submission of the report. The FMECA is an essential reliability task, it also provides information for other purposes. The use of the FMECA is called for in maintainability, safety analysis (Refer to System Safety Program Plan, CDRL IBCS-A028), survivability and vulnerability, logistics support analysis, maintenance plan analysis, and for failure detection and isolation subsystem design. The basic interrelationships of the tasks called out in MIL-STD-1629A are shown in Figure 1-1. The tasks to be performed are shown by the heavy black lines.

Figure 11. Interrelationships of the Tasks

Purpose The IBCS FMECA Results establish requirements and procedures to systematically evaluate and document, by item failure mode analysis, the potential impact of each functional, hardware, or software failure. The impact of this failure is then evaluated in light of: mission success, personnel and system safety, system performance, and maintainability and maintenance requirements. Each potential failure is classified by the severity of its effect in order that appropriate corrective actions may be taken to eliminate or control the high risk items.

Scope These results apply to all IBCS product hardware and software and will be used during the design phase to analyze the hardware and software design and any modifications thereafter. The results apply to IBCS, Command Posts (also known as Engagement Operation Centers), and Plug and Fight B-Kits (also known as IFCN [Integrated Fire Control Network] Relays). The IBCS FMECA Results were developed as Contract Data Requirements List (CDRL) IBCS-A243 and developed using MIL-STD-1629A, Task 105 and TM 5-698-4 as guides.

Application of Analysis Results The results of this FMECA will be used to identify all catastrophic and critical failures so they can be eliminated or controlled through design or procedural modifications at the earliest possible time. The FMECA is also used to improve the reliability and availability of the system, to design testability into the system, and as an aid to developing corrective and preventive maintenance tasks. And, can assist in establishing a Reliability Centered Maintenance (RCM) program. It also supports personnel safety assessments, logistics analysis, risk assessment, and mission performance analysis in conjunction with supporting the development of a fix or fight criteria. Sections 6 and 7 provide more details as to how the results will be applied.

Document Overview

Results Updates This FMECA Results are updated due to changes in the contract, customer direction, program scope, requirements, available and estimated resources, organizational policies or processes, or when actual values vary significantly from the existing results. The results shall be reviewed for updates at least every six months and revised as contracted for. More frequent reviews and updates are performed as necessary to ensure that the results are current and useful. There have been no design changes to IBCS since the release of IBCS-A052-012 (previous report) that necessitate changes to these results. Updates are subject to the configuration and change management process defined in CDRL IBCS-A058, the IBCS Configuration Management Plan (CMP).

Program Overview The Army Integrated Air and Missile Defense (AIAMD) System of Systems (ASoS) integrates current and future sensors, weapons, and their respective Mission Command (MC) into a networked Air and Missile Defense (AMD) system. The materiel solution for the ASoS MC is the IAMD Battle Command System (IBCS).

IBCS provides the net-centric, Plug and Fight (P&F), SoS Command, Control, and Communications, Computers, Intelligence, Surveillance, and Reconnaissance (C4ISR) capability of the IAMD architecture. IBCS consists of two Major End Items (MEIs): the Engagement Operations Center (EOC) (also known as the Command Post (CP)), and the IBCS IFCN Relay (also known as the P&F B-Kit). The IBCS EOC provides C4ISR functions at battalion (BN), battery (BTRY), and platoon (PLT) echelons within the AMD Task Force (TF), while the IFCN Relays adapt IAMD weapon and sensor components to fight in the net-centric ASoS. The P&F A-Kit provides the component-unique portion of the P&F Kit and is developed under the purview of the affected component’s project/product office. The IFCN Relay (P&F B-Kit) provides the interface between the component P&F A-Kit and IBCS. Northrop Grumman is supplying the IBCS EOCs and the IBCS IFCN Relays. The EOCs and the IFCN Relays draw from a set of common software modules that provide track management, engagement operations, interface services (both human and machine), planning, training and supporting software infrastructural needs. In addition, IAMD weapon and sensor program offices provide the unique hardware and software items used for integration of IBCS IFCN Relays with their system’s P&F A-Kit. Northrop Grumman is also developing the IBCS IFCN that provides the framework to distribute fire control quality data, commands, and messaging among IBCS EOCs and ASoS enabled weapons and sensors. The IBCS EOC serves as the AMD MC node at BN, BTRY and PLT levels within the AMD TF.

The AIAMD FY16 Architecture Concept, as defined by the IAMD Project Office (PO), is shown in Figure 11, and includes IBCS, Lower Tier Project Office (LTPO) sensors and weapons, Cruise Missile Defense Systems (CMDS) Project Office sensors and weapons, as well as the IFCN.

Figure 12. OV1- High Level Operational Concept.

The IBCS architecture enhances the Warfighter’s ability to execute AMD battle command. By modernizing command and control, the kinematic capabilities of all weapons and detection and tracking envelopes of all sensors can be fully utilized. By establishing and invoking the common standards sought by the Joint IAMD, the vision of a truly joint IAMD is realized. This innovative approach at modernization reduces manpower, enhances training, and reduces operation and support cost while at the same time providing a more robust and effective AMD.

Applicable Documents The documents listed in this section form a part of this report to the extent specified herein.

Government Documents Table 2-1 lists Government documents relevant to the FMECA effort.

Table 21. Government Reference Documents

Northrop Grumman Documents Table 2-2 lists documents generated by Northrop Grumman or other team members used in development of the IBCS FMECA and this report.

Table 22. Northrop Grumman Documents

Output Products The following items are produced as a result of performing a FMECA and will be provided to the MEI designers for design improvement considerations:

Design and maintainability information for fault detection implementing Built-In Test (BIT) and/or Continuous-BIT (C-BIT) capability data and maintenance tasks will be incorporated into the Reliability, Availability and Maintainability (RAM) Prediction and Analysis Report (CDRL IBCS A241-003). As the system matures, information will be updated. At the present time C-BIT is limited due to lack of funding.

Critical Items List (CIL) (See Section 6.6.1) (MIL-STD 1629A General Requirement 4.5.2.1) To be incorporated as the system matures Criticality Matrix (See Section 6.6.4) (MIL-STD 1629A Figure 102.2 Task 102) To be determined

System Overview The IBCS capability includes the IBCS EOC, IFCN Relays, and the IFCN. All three components are tied together and driven by the IBCS software. The IBCS architecture enables IBCS EOCs capable of supporting operations at echelons Platoon through Battalion IAMD TF connected via the IFCN to sensor and weapons through IFCN Relays which provide the means to interoperate with existing sensors and weapons.

S-280 EOC

IBCS S-280 EOCs are configurable facilities used by IAMD ASoS commanders and staffs to control AMD forces. Each will contain a similar capability tailored to the mission requirements of each respective echelon. The configurations of the EOC at each echelon are scaled to match required capabilities both in size and capability. The IBCS EOC consists of a standard Army prime mover (Family of Mobile Tactical Vehicles [FMTV] M1148A1P2), S-280 shelter with IFCN communications equipment, and trailer containing a tactical generator, deployable IBCS Collaboration Environment (ICE) tent, ICE Environmental Control Unit (ECU) ICE primary operational components, and ancillary support equipment. Additionally, the IBCS EOC will use Non-Developmental-Item (NDI), Commercial Off-the-Shelf (COTS), Government-furnished equipment (GFE), and developed Common Software Modules (CSMs) within EOC software builds. The IBCS EOC design maximizes commonality across BN, BTRY, and Platoon echelons. IBCS uses a common vehicle and shelter as the EOC for all echelons to maximize commonality.

IBCS EOC hardware design maximizes the use of the Army’s Standardized Integrated Command Post System (SICPS) Highband Digital Transceiver (HDT) Small Tactical Air Beam Tent (STAT, model 2021). The FMTV (shown in Figure 4-1 with IBCS EOC components) replaced the originally selected prime mover due to availability of the vehicle.

Engagement Center Trailer (ECT) The ICE is transported and stored on the Engagement Operation Center Trailer (ECT) (Figure 4-1), an Army standard M1061A1P2 cargo trailer which carries a standard Army standard 60Kw Generator and an improved ECU, and the HDT AirBeam tent. The ECT provides cargo transport capability for the ICE and Ancillary equipment (e.g. transit cases).

The EOC Prime Mover subsystem includes Joint Battle Command Platform (JBC-P) (incorporating updated Force XXI Battle Command Brigade and Below (FBCB2) Joint Capabilities Release (JCR) and Blue Force Tracker 2 (BFT) capabilities) in the FMTV M1148A1P2 cab and auxiliary power generator, cabling, breakout boxes and work platforms externally.

Figure 41. FMTV with IBCS S-280 EOC and Trailer

FMTV

The M1148A1P2 is a 6x6 wheeled vehicle with a long wheelbase. The IBCS design will utilize the vehicle chassis for mounting the S-280 EOC shelter on a Container Roll-On/Off Platform (CROP).

The FMTV includes an armor-ready cab with seating for a driver and two passengers. The cab can be upgraded with additional bolt-on armor for increased crew protection. The turbocharged diesel engine produces 330 hp (246 kW), and the fuel system includes a 56 gal (212 L) capacity fuel tank. The overall length is 29 ft. 4 in. (8.9 m), overall width is 8 ft. (2.4 m), and overall height is 9 ft. 4 in. (2.8 m). The curb weight is 26,041 lbs. (11,812 kg) without IBCS components installed. The maximum operating speed without the bolt-on armor or installation of IBCS components is 55 miles per hour.

IBCS S-280 EOC Shelter The S-280 EOC Shelter, as shown in Figures 4-2, 4-3, and 4-4, is the basic building block for IBCS EOCs.

Figure 42. IBCS S-280 EOC Shelter Roadside View

Figure 43. IBCS S-280 EOC Shelter Curbside View

Figure 44. IBCS S-280 EOC Shelter Exterior Isometric View The IBCS S-280 EOC is rapidly-deployable with two operator stations to establish minimum functionality while the ICE is being deployed and maintain minimum functionality should the ICE be unavailable.

The EOC is common at all echelons and host multiple IBCS, battle command and combat service support software suites, and communications equipment, and interface with numerous non-battle command vehicles to serve as an information aggregation point. The common shelter includes rack designs and cabling for installation compatibility of all required IBCS radios. The common cable infrastructure based on the S-280 product line provides common interfaces for data, power, radio frequency (RF), and audio connections in every EOC. The IBCS S-280 EOC development will be an extension of the Northrop Grumman existing Command Post Platform (CPP) hardware product line.

The key feature and primary assembly of the EOC shelter is the MC Assembly, a common suite of electronics. The MC Assembly consists of a computer/server system, a networking system connecting to the IFCN, a communication system which includes provisions for mounting radios, and the Command Post Communication System (CPCS) Tactical Operations Communications Network (TOCNET). The common MC Assembly eliminates unique parts at each IBCS echelon, reduces the training burden on Soldiers, ensures commonality, and reduces the logistics burden on units. The Tent Interface Panel (TIP) provides NIPR/SIPR fiber connections to the ICE workspace, and the Signal Entry Panel (SEP) provides for fiber connections to A-side interfaces and alternate media. The EOC Shelter contains the common Highband Network Radio (HNR) components.

ICE

The ICE consists of self-contained STAT (Small Tactical Air Beam Tent) in which to conduct battle command at the halt. The STAT systems are quickly erectable, electromagnetic interference (EMI)-protected, and designed to be standalone or connected to other SICPS tents or shelters. Modular by design, they are able to be connected end-to-end, side-to-side, or side-to-end. The tents are employed with operational facilities of IBCS EOCs to provide open ICE workspace, power distribution, lighting, environmental conditioning (heating and cooling), tables, lightweight/integrated flooring, and a common grounding system for the staffs. Figure 4-5 shows an ICE layout.

Figure 45. ICE Layout ICE tents and support equipment are transported on a large tactical trailer derived from the standard TMSS (Trailer Mounting Support System) family of products. The trailer provides generator power, an ECU, and cargo space for support equipment. The ICE is issued at BTRY and BN echelons. The ICE at BN echelons supports the full range of AMD operational tasks. The EOC ICE provides for the collocation and integration of Functional and the integrating cell activities. The Platoon echelon consists of one IBCS shelter with prime mover and generator. Addition of one ICE produces the BTRY echelon. The BN echelon is twice the BTRY echelon, consisting two shelters and two ICEs. All shelters and ICEs are common and interchangeable among echelons.

IFF System As shown in Figure 4-6, the IBCS stand-alone Identification Friend or Foe (IFF) capability is employed through the use of a receiver transceiver located on a rack inside of the EOC Shelter. A corresponding set of IFF system antennas consisting of a Global Positioning System (GPS) and IFF unique antenna is located on the external surface of the EOC Shelter mounted on the roadside rear portion of the shelter.

Figure 46. IBCS IFF System

IFCN

The IFCN consists of network components and transport media used for voice, data, and video information exchanges between IBCS components. From a network perspective, a component includes a radio interface to the IFCN connected to an intra-nodal LAN. IBCS uses the Harris Warfighter Information Network Tactical (WIN-T) Increment 2 interoperable HNR, consisting of the Baseband Processing Unit (BPU) and Highband Network Waveform (HNW) RF Unit (HRFUe2-8Wch) antenna. Figure 4-7 shows the HRFUe2-8Wch antenna. The IFCN node hardware is common to and a part of each MEI (EOC, IFCN Relay) described in subsequent sections. Network communications components are integrated within the EOC Shelter with connections to the necessary external antenna components, while on the IFCN Relay they reside within the network with connections to the external antenna components mounted to the mast assembly.

Left: component photograph; Right: as integrated onto IFCN Relay mast Figure 47. HRFU Antenna The HRFUe2-8Wch antenna utilizes directive beam technology to achieve high-throughput mesh networking over long distances with enhanced spectrum efficiency. The antenna consists of 15 elements in the horizontal plane and one element at zenith. The technology takes advantage of the directive beams to determine links that do not interfere and allows multiple nodes to transmit and receive using the same time slot. This accomplishes a distributed architecture where radios track time division multiple access time slots and transmit on non-interfering links.

The IFCN nodes consist of common hardware across all configurations. All configurations utilize common hardware elements and interfaces across platforms that facilitate integration and maximum effective reuse. Figure 4-8 depicts the IFCN Network Node.

Figure 48. IFCN Network Node Architecture

HNR components, including the network encryption elements, are used for all configurations. Hardware commonality and use of WIN-T and COTS components in IFCN hardware ensure easy maintenance and spare parts provisioning.

The HNR components include the BPU and a High Assurance Internet Protocol Encryptor (HAIPE) 3.0 encryption device, with supporting equipment that includes the Timing Unit with Selective Availability Anti-Spoofing Module (SAASM) GPS receiver, Integrated GPS Receiver Module (IGRM), and Status Coordinate Input Module (SCIM). The BPU includes the control processor that hosts the Highband Networking Waveform version 2 (HNWv2) data link control layer and an Orthogonal Frequency-Division Multiplexing burst modem that provides the HNWv2 physical layer. The HAIPE 3.0 encryption device maintains the red/black communication boundary for all IFCN communication. The timing unit and IGRM provide position, timing signal (1 Pulse per Second [1PPS]), and time of day information to the BPU.

V2 IFCN Relay During Engineering and Manufacturing Development (EMD) the IFCN Relay has evolved from the original version, called the V1 IFCN Relay to the V2 IFCN Relay. The V2 IFCN Relay, shown in Figure 4-7, is the second version of this MEI. The main difference is the GFE M1061A1P2 trailer and palletized mast assembly, which was changed to allow greater flexibility and increased load. It provides network components and transport media used for voice, data, and video information exchanges between IBCS components to allow a 150-km range. The Tactical Mast Trailer (TMT) is the Government-provided platform in which the hardware and software provide the V2 IFCN Relay (also known as P&F B-Kit) functionality to meet the IBCS performance requirement of a mobile IFCN communications node, with B-Kit functionality and interface, which extends connectivity to remote launchers and sensor platforms. The IFCN Relay can also function as a stand-alone IFCN communications relay to expand the range of Line-Of-Sight (LOS) communications over the horizons and around intervening terrain features.

Figure 49. V2 IFCN Relay

An IFCN Relay contains a HRFU, a ePFPU and a fully integrated network enclosure. The network enclosure consists of the IFCN radio and its components, a time and frequency reference system, encryption devices, a classified Ethernet switch, and fiber media converters for A-side connectivity. All necessary external connections including A-Kit adapted sensors and weapons utilize media converters with Tactical Fiber Optic Assembly (TFOCA-II) cable.

The IFCN Relay platform includes a 3kW generator. It includes an antenna mast housing the HRFUe2-8Wch antenna and HRFU connections for power, control, and RF that feed into the network enclosure.

Each Relay is connected to the receiving platform’s A-kit, Launcher Integration Network Kit (LINK), or other A-side connection. Details of the Relay interface with the Component Acquisition Programs (CAPs) may be found in MIS-DTL-56502, P&F B-Kit to A-Kit Interface Control Document (ICD).

ePFPU The ruggedized Enhanced Plug and Fight Processing Unit (ePFPU) consists of two Line Replaceable Units (LRUs) – the ePFPU and a Network Attached Storage (NAS). The ePFPU is a ruggedized enclosure containing six Single Board Computers (SBC), an Ethernet switch, two 800w power supplies, and supporting hardware (e.g., power distribution, structure). The ruggedized ePFPU operates at a nominal 28 VDC. The Processing Unit is a forced-air-over-conduction cooled 3U Open Voice Protocol Exchange (VPX) chassis. The forced air is pulled by the fan assembly through the air inlets along the front of the unit, and expelled out the rear. A 3U Open VPX form factor has been selected for its compact size and heat dissipation qualities.

Processors are loosely coupled via ten-gigabit backplane Ethernet connections. Ethernet also supports all connections external to the ePFPU. Within the red domain, a multi-layer Ethernet switch manages switching. These switches have transient voltage suppressors on each port to protect from Electrostatic Discharge (ESD), cable discharge, lightning, and other induced voltage surges. They have built-in test capability, security features, and Internet Protocol (IPv6) capability, while supporting speeds up to ten gigabit (Gb) per second. The ePFPU provides computing capabilities suitable for rugged, all-weather environments.

The NAS is a rugged enclosure housing solid state drives and control electronics. The NAS is the storage/hard drive for the ePFPU. The NAS has a removable storage bay at the top of the device that can be used for data harvesting and data transfer. The ePFPU chassis provides accommodations for mounting the NAS directly to it, either on the top or the side.

At the present time (10-10-2019), the ePFPU being re-designed.

Analysis Guidelines This section of the report lists the ground rules and assumptions used for Reliability Availability, and Maintainability (RAM) modeling, and describes the mission phases, operational modes and environmental profiles. It also explains the data source hierarchy used for RAM modeling and explains the block diagrams employed.

The Reliability Block Diagrams (RBDs) and mathematical models are not used only to assess the reliability metrics of IBCS and its sub-systems. These models are also used to improve these metrics for the systems. The RBDs and mathematical models are contained in CDRL IBCS-A241, the Reliability, Availability, and Maintainability Prediction (RAM) Report Mission Phases and Operational Modes In this initial FMECA, the results are looked at a high level, as the system of systems matures the Mission Phases and Operational Modes will be defined and particular instants will be called –out. At the present time, “All phases” will be considered due to the “mission phase and operational mode” have not been clearly defined.

An implication is made in the Failure Definition and Scoring Criteria (FDSC) Report Section 5 (27 Jan 2016) that a k-of-n model is present during operations. This allows the assumption to be made that Maintenance and Operations can be performed concurrently, i.e. that is a part of the system can be taken down to perform a particular type maintenance without taking the entire system off line.

System Definition and Mission Time The system definition provides a functional description of the system to be analyzed. Functional narratives must be developed for each mission, mission phase and operational mode, and include statements of mission objectives. The narratives will include system and part descriptions for each mission phase and operational mode, As stated above, “All phases” will be considered due to the “mission phase and operational mode” have not been clearly defined.

A quantitative statement of system function-time requirements will be developed and included in the system definition (when available). Function-time requirements will be developed for items that operate in different operational modes during different mission phases and for items which function only if required. The function-time requirements are developed by Reliability Engineering, Design, and Logistics Engineering using the Operational Mode Summary / Mission Profile (OMS/MP), MIS-PRF-56500E, and other specifications as appropriate.

It is currently assumed that all hardware operates with mission pulse (72 hours) during emplacement as called-out in Section 5 of the FDSC. The mission pulse is used in the calculation of the Failure Mode Criticality Number (Cm).

Environmental Profiles The environmental profiles which present the anticipated environmental conditions for each mission and mission phase will be defined. These profiles are developed by Reliability Engineering and Design personnel using the OMS/MP, MIS-PRF-56500E, and other specifications as appropriate. At the present time a system is only being considered in the ground fixed environment. As the system matures a more extensive examination will be performed. CDRL IBCS-A241, contains more information on how environments are incorporated into future analysis.

Functional Diagrams A functional block diagram provides a functional flow sequence for the system and each indenture level of analysis and present hardware indenture used for both hardware and functional method FMEA’s. MIL-M-24100 procedures and techniques for developing major functional diagrams may be used for guidance in developing functional block diagrams.

At the present time the functional diagrams are being developed to depict the functional flow sequence for the system and each indenture level of analysis and present hardware indenture used for both hardware and functional method.

Data Sources and Techniques Design data for these analyses ideally come from approved drawings, although prior to the development of a complete set of such drawings, Engineering Review Board (ERB)-approved sources are also used. Product drawings will be delivered in CDRLs IBCS-A244. IBCS parts are chosen using the Parts, Materials, and Processes Management Plan, 01K698.IBCS.System Engineering & Integration (SE&I)-002, which is a part of CDRL IBCS-A238, the Program Product Assurance Plan.

The initial modelling effort was accomplished by a team of engineers using software created by Diagnostics Support Integrator (DSI) International, Inc. Much of the current FMECA was structured using this information.

The output product yields failure modes for the particular LRU being examined. In many cases, a LRU will have many output ports. An individual port can have numerous failure modes. The preliminary analysis contained in Appendix A and Appendix B shows the failure mode break-down. This information is used to calculate the criticality numbers.

As updated information becomes available it will be incorporated in a timely manner.

At the present time, all failure rate data at an LRU level is provided by the Vendor (COTS). Currently the failure rate data is being updated (10-01-2019). The updated values are reflected in the appropriate Appendixes (more information) of the report (bold font). As vendor data is received it will be incorporated into the report. Also, in the future, IBCS Reliability Engineering hopes to establish a tracking process to monitor LRU revisions and/or ECPs.

FMECA Analysis Overview A FMECA is typically performed using a functional approach, a hardware (and software) approach, or a combination of the two. The functional approach analyzes the effects that a system or sub-system has on a specified mission. This approach is often performed in a top-down manner, and a failure mode description using the functional approach is a functional description of a failure, such as “motor failure”. A hardware approach lists individual hardware items and analyzes their possible failure modes. The hardware approach is normally performed from the bottom up and a failure mode description for this approach is often the identification of a failed part of the item, such as “motor windings are open”. The approach used for a specific FMECA is usually dependent on the amount and type of information available. A functional approach requires knowledge of system functions and theory of operation whereas the hardware approach necessitates the use of detailed design information such as schematics. Often, it is necessary to use both approaches to get the most use of the information available. The IBCS FMECA will use both approaches, but will use the hardware approach when sufficient information is available and appropriate to the goals of the FMECA. The FMECA will be performed at the LRU hardware level due to the two-level maintenance requirement levied on the program. Note that the FMECA is an evolving analysis, starting early in the design phase to maximize the benefits of the analysis. As such, the analysis starts using mostly the functional approach and as more details become available, the analysis transitions to being more of a hardware/software FMECA.

The functional-level approach can be used when the hardware cannot be uniquely identified or may be used early in the program until the design matures, although a hardware FMECA is preferred.

Excluded from this FMECA are GFE and Military Off the-Shelf (MOTS) items. However, if any of the GFE or MOTS items interface with IBCS hardware, a FMECA will be performed for the GFE and MOTS at the interface level looking from the perspective of the IBCS hardware. For GFE, GFE manuals will be used for information on failure detection methods when available.

Software developed on the program will typically be analyzed at the Software Configuration Item (SCI) level by the time of the critical design phase of the program. Software, both program-developed and non-developed, will be analyzed using a functional approach, where the software functional outputs are listed and their failure modes analyzed. The FMECA will consider interfaces between hardware items, between software items, and between hardware and software items. Details of how IBCS software is developed and maintained are found in CDRL IBCS-A220, IBCS Software Development Plan.

The Software FMECA is contained in Appendix C.

Analysis Approach When possible, the FMECA utilizes inductive logic in a bottoms-up approach. Beginning at the lowest level (LRU) of the system hierarchy, and from a knowledge of the failure modes of each piece of hardware and software, the analyst traces up through the system hierarchy to determine the effects that each failure mode will have on system performance.

Lower-level FMECA may be required on a case-by-case basis where Category I (per Table 6-1) and single point of failures exist.

Unless otherwise specified, the following discrete steps will be used in performing a FMECA:

1. Define the ground rules and assumptions to be used in the analysis. This step will start with the ground rules and assumptions contained in this report and review them to see if there are any exceptions or additions due to changes or additional information since the release of this report. Any changes to the ground rules and assumptions need to be reflected in this report and approved by the Government. Section 6.2 contains the baseline set of ground rules and assumptions.

2. Construct block diagrams. RBDs which illustrate the operation, interrelationships, and interdependencies of functional entities will be obtained or constructed. The RBDs are illustrated in CDRL IBCS-A241.

3. Complete the combined FMEA and Criticality Analysis (CA) worksheets. (Appendix A through Appendix C)

4. Create a Critical Items List, and Criticality matrix: A Preliminary Analysis presented for every critical LRU in spreadsheet form. The information is present in the appropriate Appendices (Appendix A and Appendix B)

5. Create a summary of conclusions, interpretations, and recommended corrective actions based on the analysis results.

6. Document the analysis and report the results.

The resulting FMECA report contains a summary of the results, data sources, techniques used, system definitions and block diagrams, worksheets, and conclusions and recommendations. Results are provided to IPTs and other program management. Results may also be reported to the program through the SE&I Working Product Integration Team (WIPT), which contains representatives from each Integrated Product Team (IPT). Figure 6-1 summarizes the steps required to perform a FMECA.

Figure 61. FMECA Process Flow

The hardware and software approach was chosen since the hardware/software can be identified from schematics, drawings, and other engineering and design data. This approach is normally utilized in a bottoms-up approach; however, it can be initiated in either direction. Each identified failure mode will be assigned a severity classification which will be utilized during design to establish priorities for corrective actions.

Ground Rules and Assumption The ground rules for the IBCS (S-280) FMECA/ Analysis are as follows:

1. Analysis is provided at the EOC and Relay level which is constant with the MTBFc requirements.

2. A failure is defined as an event, or inoperable state, in which any item or part of an item does not, or would not, perform as previously specified.

3. An IBCS mission critical function is defined an IBCS function whose failure results in the loss of the ability to perform Engagement Operations or a severe degradation in that ability.

4. A mission critical failure is a failure of hardware or software resulting in a failure mode that prevents a mission critical function from being performed or that severely degrades the performance of that function.

5. The Two - Level Maintenance program allows the Operator/ Maintainer to remove and replace the faulty component (LRU). Therefore limiting the identification of failure modes and effects to the output of the faulty LRU.

6. For Reliability Engineering, a mission critical part is any hardware or software that has a critical failure mode. These items are identified in the appropriate Appendix of this document

7. All predictions are for a mature system Failure modes induced by human error are included if the failure mode is considered to be reasonably plausible.

In general, a system can have only one independent failure cause at any given time (i.e., no multiple independent failures occurring at the same time are analyzed). Exceptions are made on a case-by-case basis when additional analysis is needed to fully understand the significance of the failure. The FMECA does consider multiple failure effects, effects at different levels of the system, and the impact of redundancy. Note that a failure effect is different than a failure cause and a given failure effect may result from multiple potential failure causes.

All consumables are present in sufficient quantities unless otherwise stated.

All inputs (including software commands and power) to the item being analyzed are present at nominal values unless otherwise stated.

At this time, failure rate data from field experience is very limited. The most recent fielded findings are found in CDRL IBCS-A241-003.

Initially the primary source of data is MIL-HDBK-217F. As the systems matures, vendor data and actual field data will be used to supplement the calculated values. At the present time the failure rates for the critical LRUs are being re-evaluated and supplemented by vendor findings

Classification of failures uses the following guidelines:

· The FDSC for Integrated Air and Missile Defense System-of-Systems (IAMD SoS) will be used as a guide in determining failure severity. Also, severity levels will established IAW the reliability block diagrams (as needed) and the defined mission essential functions.

· Severity classification criteria are determined as shown in Tables 6-1 and 6-2. These tables define and describe the different severity classifications that failures of functions can have. The different classifications are used to isolate the different types of failure implications. Table 6-1 addresses the traditional combined safety and reliability failure severity levels. Table 6-2 addresses reliability and the effects of redundancy. The severity classification for safety is not intended to replace traditional safety classifications but rather to supplement safety analyses by adding FMECA-generated potential safety issues. For example, redundancy considerations may reduce the severity classification from Category II to a Category III-2R, meaning that a failure that could have been a critical failure has been mitigated to a marginal failure through the use of redundancy.

· Severity classifications are made on the basis of the worst case potential effects. This guideline helps determine the functional effect of a given failure.

Table 61. Reliability Severity Classification Criteria

Due to the configuration flexibility of the IBCS System Table 6-2 was created. The rows labeled Category III-1R and Category III-2R allows for the Severity Classification to be modified when the system is re-configured to incorporate redundancy.

Table 62. Reliability Expanded Severity Classification Criteria

Figure 6-2 illustrates the specified configuration of the IBCS System. Redundancy is incorporated at the EOC level, in conjunction with the k-of-n configuration of the ICE

Figure 62. Specified Configuration of the IBCS System.

Also, the configuration of the IFCN Relay is multi-functional for more information refer to of Failure Definition and Scoring Criteria (FDSC) Report Section 5 (27 Jan 2016) Throughout the system, EOC and IFCN Relay, there are many redundant and k-of-n configuration that allows the reduction of Severity Classification Categories I and II to a less severe Category III (Appropriate Appendix and LRU Spreadsheet).

Coding System For consistent identification of system functions and equipment and for tracking failure modes, the FMECA adheres to a system of alpha-numeric identifiers generated earlier by a FMECA software tool, with component name, drawing number, and part number used for consistency. As system maturity is achieved, the hardware/software will be identified by a Work Unit Code (WUC) structure define in MIL-PRF-49506. The FMECA indenture coding system will be consistent with the reliability and functional block diagram numbering system to provide complete visibility of each failure mode and its relationship to the system. When available the Logistic Support Analysis (LSA) Control Number (LCN) is provided. The LCN’s are provided in the appropriate Appendixes.

The IBCS FMECA is typically at a higher level than the piece-part level. Since the program uses mostly COTS, MOTS, and Government Off-the-Shelf (GOTS) hardware, a detailed piece-part level approach may not be possible for many items. In the event that further analysis is warranted, FMECA at the piece-part level can be performed on a case-by-case basis, given that sufficient data are available. The IBCS FMECA is performed at the LRU level due to the two-level maintenance requirement. This includes all COTS, MOTS and GOTS products.

Software is included as a part of the same higher-level assembly as the hardware that hosts the software. When appropriate, the software hosted by a given piece of hardware is divided into software modules. These software modules interact with other modules in the same hardware host, and possibly with other modules hosted by other hardware as well. Interactions between hardware and software are also included where appropriate. The Software FMECA Results is referenced as an Appendix to the Hardware FMECA Results.

FMECA Review and Schedule The FMECA may require updating due to changes in the design or changes in the FMECA. Updates to the FMECA are scheduled for the same timeframe as the releases of CDRL IBCS-A241, to provide consistent information. More frequent and periodic FMECA status reviews may be required for all Critical Items until they are dispositioned. The FMECA is reviewed by the appropriate organizations and/or IPTs. Updates are subject to the configuration and change management process (CMP) defined in CDRL IBCS-A258, the IBCS CMP.

Prior to the release of the first formal FMECA, draft versions are produced “as needed” to ensure that the analysis provides adequate feedback to the design.