Attachment 10g - IBCS - 243-003 HW FMECA Results.pdf

UNCLASSIFIED-For Official Use Only

Copyright 2019 Northrop Grumman Systems Corporation.

IBCS.DM.025.24 (Jan16)

Integrated Air and Missile Defense

(IAMD) Battle Command System (IBCS)

IBCS Failure Modes, Effects and Criticality Analysis

Hardware (FMECA) Results

DOCUMENT NUMBER: RELEASE: DOCUMENT DATE:

IBCS-A243-003 003 01 Nov. 2019

CDRL NUMBER: CONTRACT: CONTRACT NUMBER:

A243 IBCS W31P4Q-08-C-0418

Systems Engineering & Integration Document

EXPORT CONTROL WARNING DISTRIBUTION STATEMENT D

WARNING -This document contains technical data whose export is restricted by the Arms Export Control Act (Title 22, U.S.C., Sec 2751,

et. seq.) or the Export Administration Act of 1979, as amended, Title

50, U.S.C., App. 2401 et. seq. Violations of these export laws are subject to severe criminal penalties. Disseminate in accordance with provisions of DoD Directive 5230.25.

Distribution authorized to the Department of Defense and U.S. DoD contractors only (fill in reason) (date of determination). Other requests shall be referred to the Program Executive Office Missiles and Space, Integrated Air and Missile Defense (IAMD) Project Office, ATTN: SFAE-MSLS-IAMD, Bldg. 5250 Martin Road, Redstone Arsenal, AL 35898-8000.

DISCLAIMER STATEMENT AND DISTRIBUTION

RESTRICTION

FOR OFFICIAL USE ONLY

The views, opinions, and/or findings contained in this report are those of the author(s) and should not be construed as an official

Department of Defense position, policy, or decision, unless so designated by other official documentation.

This document contains information EXEMPT FROM

MANDATORY DISCLOSURE under the FOIA. Exemption 3e applies. (Reference: Army Regulation 25-55)

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

Prepared for: Prepared by:

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

IBCS-A243, Rel. 003

01 Nov. 2019 ii

Integrated Air and Missile Defense (IAMD)

Battle Command System (IBCS) Failure Modes, Effects and Criticality Analysis

Hardware (FMECA) Results

Approval Sheet

SIGNATURES FOR RELEASE:

Author: /signature on file/

Jon Tegtmeier, IBCS Reliability Engineering Date

Approved By: /signature on file/

Andrew Sutinen, IBCS Reliability Engineering Lead Date

Approved By: /signature on file/

Daiven Harper, Specialty Engineering Manager Date

Approved By: /signature on file/

Mike Myszka, IBCS SE&IPT Manager Date

Approved By: /signature on file/

Lori Tatom, IBCS Mission Assurance Manager Date

Approved By: /signature on file/

Mark Rist, IBCS Program Director Date

Document Release: /signature on file/

Kristi Fugit, IBCS Configuration/Data Management Date

Document Type:

e.g., Systems Engineering & Integration

Preparing Organization (if different from owning organization) Hardware and Software Used

N/A PC Microsoft Office Suite

Notes or Comment:

N/A

01 Nov. 2019 iii

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 Authority

Pages

Affected Remarks

27 Feb 2019

2 Aug 2019

SOW

SOW

All

All

DCR-6090, Initial Release

DCR-6159, Resubmittal Due to Rejection

003 1 Nov 2019 SOW All DCR-6257, Resubmittal Due to Rejection iv

Contents

1. Introduction

1.1. Purpose

1.2. Scope

1.3. Application of Analysis Results

1.4. Document Overview

1.5. Plan Updates

1.6. Program Overview

2. Applicable Documents

2.1. Government Documents

2.2. Northrop Grumman Documents

3. Output Products

4. System Overview

4.1. S-280 EOC

4.1.1. Engagement Center Trailer (ECT)

4.1.2. FMTV

4.1.3. IBCS S-280 EOC Shelter

4.1.4. ICE

4.1.5. IFF System

4.2. IFCN

4.3. V2 IFCN Relay

4.4. ePFPU

5. Analysis Guidelines

5.1. Mission Phases and Operational Modes

5.2. System Definition and Mission Time

5.3. Environmental Profiles

5.4. Functional Diagrams

5.5. Data Sources and Techniques

6. FMECA Analysis Overview

6.1. Analysis Approach

6.2. Ground Rules and Assumption

v

6.3. Coding System

6.4. FMECA Review and Schedule

6.5. FMEA/FMECA Worksheets

6.6. FMEA Report

6.6.1. Critical Items List

6.6.2. Safety Impact

6.6.3. Continuous Built – In Test (C-BIT)

6.6.4. Criticality Matrix

6.7. A Brief Example

7. Summary and Conclusion

8. Abbreviations and Acronyms

Appendix A. IFCN Relay

Appendix B. EOC (Engagement Operation Center)

Appendix B.1: “Shelter”

Appendix B.2: “ICE”

Appendix C. Link to SWFMECA vi

List of Figures

Figure 1-1. Interrelationships of the Tasks Figure 1-2. OV1- High Level Operational Concept Figure 4-1. FMTV with IBCS S-280 EOC and Trailer Figure 4-2. IBCS S-280 EOC Shelter Roadside View Figure 4-3. IBCS S-280 EOC Shelter Curbside View

Figure 4-4. IBCS S-280 EOC Shelter Exterior Isometric View Figure 4-5. ICE Layout Figure 4-6. IBCS IFF System

Figure 4-7. HRFU Antenna Figure 4-8. IFCN Network Node Architecture Figure 4-9. V2 IFCN Relay

Figure 6-1. FMECA Process Flow Figure 6-2. Specified Configuration of the IBCS System Figure 6-3. FMECA Format Worksheet

List of Tables

Table 2-1. Government Reference Documents

Table 2-2. Northrop Grumman Documents Table 6-1. Reliability Severity Classification Criteria

For Official Use Only

1. 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 1-1. Interrelationships of the Tasks

Document Analysis/ Report Results

Task 103 FMECA-Maintainability

Information Plan

Task 104 Damage Mode & Effects

Analysis Plan (Safety)

Task 101 - FEMA

Task 102 - FMECA

Document Analysis/ Report Results

Document Analysis/ Report Results

Task 105 FMECA Plan

Input:

Information pertaining to Critical LRUs and associated parts

Develop Recommendations to Improve Reliability/MTBF, Identify Design Changes, Generate Single Point Failure List, Critical/Safety Item List

Identify & Develop Recommendations To Improve Maintainability & Maintenance Procedures (IETM Development)

Identify & Develop Recommendations To Improve the monitoring of Safety Critical Items

Task 105: DI-R-7086 Task 101: DI-R-7085 Task 102: DI-R-7085

1.1. 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.

1.2. 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.

1.3. 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.

1.4. Document Overview

Section 1 Introduction: Describes purpose, scope, application of results, and updates, and provides document and program overviews

Section 2 Applicable Documents: Lists reference documents, standards, and handbooks related to these results

Section 3 Output Products: Lists documents generated based on the FMECA results

Section 4 System Overview: Provides a description of IBCS and the major end items from a reliability modeling perspective

Section 5 Analysis Guidelines:

Section 6 FMECA Planning: Describes ground rules and assumptions as well as indenture levels, the coding system, and FMECA reviews and schedules

Section 7 Abbreviations and Acronyms: Lists abbreviations and acronyms used in this document

Appendix A IFCN Relay Data

Appendix B.1 “Shelter”

Appendix B.2 “ICE”

Appendix C Link to Software Failure Mode, Effects and Criticality Analysis (SWFMECA)

1.5. 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).

1.6. 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 1-1, 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 1-2. 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.

2. Applicable Documents

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

2.1. Government Documents

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

Table 2-1. Government Reference Documents

Document ID Title

W31P4Q-08-C-0418 Attachment

Statement of Work for the Integrated Air & Missile Defense

(IAMD) Battle Command System (IBCS) Development Program

No Number, dated 23 May 2006 Army Integrated Air and Missile Defense System-of-Systems (ASoS)

Operational Mode Summary/Mission Profile

No Number, dated 27 January

Failure Definition and Scoring Criteria (FDSC) for Integrated Air and Missile Defense System-of-Systems (AIAMD SoS) Increment 2

MIL-PRF-49506 Notice 1 dated 18

January 2005

Performance Specification: Logistics Management Information

MIS-PRF-56500E System Specification for the Army Integrated Air and Missile

Defense System of Systems Increment 2

MIL-HDBK-217F Reliability Prediction for Electronic Equipment

MIL-M-24100 Manual, Technical; Functionally Oriented Maintenance Manuals for

Systems and Equipment

MIL-STD-756B Reliability Program for Systems and Equipment Development and

Production

MIL-STD-1629A Notice 2 dated 28

November 1984

Procedure for Performing a Failure Modes, Effects and Criticality

Analysis

Army Technical Manual TM 5-698-4 dated 29 September, 2006

Failure Modes, Effects and Criticality Analysis (FMECA) for

Command, Control, Communications, Computer, Intelligence, Surveillance, and Reconnaissance (C4ISR) Facilities

2.2. 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 2-2. Northrop Grumman Documents

Document ID Title

IBCS-A220-001 IBCS Software Development Plan

IBCS-A006-005 System Engineering Management Plan

IBCS-A274-001 IBCS System Architecture

IBCS-A258-001 Configuration Management Plan (CMP)

IBCS-A234-001 System Safety Program Plan

IBCS-A237-001 Program Product Assurance Plan (PPAP)

IBCS-A240-001 Non-Developmental Items (NDI) Reliability Plan

IBCS-A241-001 Reliability, Availability, Maintainability Prediction Report

IBCS-A242-001 Failure Modes, Effects and Criticality Analysis Hardware (FMECA) Plan

IBCS-A306-001 Maintainability Test Plan

3. 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

4. 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.

4.1. 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.

4.1.1. 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 4-1. FMTV with IBCS S-280 EOC and Trailer

4.1.2. 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.

4.1.3. 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 4-2. IBCS S-280 EOC Shelter Roadside View

Figure 4-3. IBCS S-280 EOC Shelter Curbside View

Figure 4-4. 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.

4.1.4. 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 4-5. 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.

4.1.5. 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 4-6. IBCS IFF System

4.2. 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 4-7. 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 4-8. 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.

4.3. 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 4-9. 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).

4.4. 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.

5. 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

5.1. 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.

5.2. 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).

5.3. 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.

5.4. 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.

5.5. 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.

6. 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.

6.1. 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 6-1. 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.

DEFINE SYTEM/ITEM INDENTURE LEVELS

DEFINE GROUND RULES/ASSUMPTIONS

IDENTIFY FAILURE MODES

PERFORM CRITICALITY CALCULATIONS

FOR ITEMS/MODES

PERFORM FAILURE EFFECTS/

CAUSE ANALYSIS

CLASSIFY FAILURE EFFECTS

CONSTRUCT BLOCK

DIAGRAMS

RANK ALL ITEMS ACCORDING

TO CRITICALITY

DETERMINE CRITICAL ITEMS

PROVIDE MAINTAINABILITY &

SAFETY INFORMATION FOR

ANALYSIS

(Task 103 & Task 104)

DEVELOP RECOMMENDATIONS TO

IMPROVE RELIABILITY &

IDENTIFY DESIGN CHANGES

Task 101

(FMEA)

Task 102

(FMECA)

IAW MIL-STD-1629A &

TM 5-698-4

(as needed)

Single Point Failure List

Criticality Matrix

Critical Item List Safety Item List

Input:

Information pertaining to Critical LRUs and associated parts

6.2. 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 6-1. 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.

Severity

Classification

Severity

Definition Severity Description

Category I Catastrophic A failure which may cause weapon system loss (i.e., aircraft, tank, missile, ship, etc.).

Category II Critical A failure which may cause major property damage or major system damage which will result in loss of mission.

Category III Marginal A failure which may cause minor property damage or minor system damage which will result in delay or loss of availability or mission degradation.

Category IV Minor A failure not serious enough to cause property damage, or system damage, but which will result in unscheduled maintenance or repair.

Table 6-2. 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 6-2. 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).

Name: Name:

"Shelter" "ICE"

Name: Name:

In: IFCN Relay IFCN Relay Out

Name: Name:

"Shelter" "ICE"

Equipment Operation Center (EOC)

Equipment Operation Center (EOC)

Severity

Classification

Severity

Definition Severity Description

Category I Catastrophic A failure which may cause weapon system loss (i.e., aircraft, tank, missile, ship, etc.).

Category II Critical A failure which may cause major property damage or major system damage which will result in loss of mission.

Category III-1R Marginal – 1R A failure of a system with redundancy which may cause minor property damage or minor system damage which will result in delay or loss of availability or mission degradation, but if redundancy fails or if all redundant systems fail, may result in a Category I failure.

Category III-2R Marginal – 2R A failure of a system with redundancy which may cause minor property damage or minor system damage which will result in delay or loss of availability or mission degradation, but if redundancy fails or if all redundant systems fail, may result in a Category II failure.

Category III Marginal A failure which may cause minor property damage or minor system damage which will result in delay or loss of availability or mission degradation.

Category IV Minor A failure not serious enough to property damage, or system damage, but which will result in unscheduled maintenance or repair.

6.3. 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…