N61331-24-SN-Q27.pdf

SOURCES SOUGHT ANNOUNCEMENT

FOR

MIXED GAS DIVING SYSTEMS

The Naval Surface Warfare Center Panama City Division (NSWC PCD) is seeking information on several subsystems for the Next Generation Mixed Gas System (NG-MGS) with the following characteristics and capabilities. Please respond if your system meets at least 90% of the goals below for any of the listed subsystems. Responses must be designed for a marine environment and meet industry standards that are relevant to that subsystem (i.e. ASTM, IMCA, IACS rules, etc.). A response with a system capable of meeting the goals of multiple subsystems is also acceptable. Footprint and source time are primary design considerations for these requests. A proposed system concept would utilize an umbilical supplied rebreather as the primary UBA. The umbilical would provide the emergency open circuit gas supply and supplement on board (rebreather) gas supplies during normal operations. In the event of an umbilical failure, the rebreather would still function, in rebreather mode, utilizing its own on board gas supply. This is just one proposed concept, other concepts with a similar footprint/gas usage metric would be accepted.

All systems will need to comply with GENSPECS rev 2.

Topside Systems

HeO2 / O2 Storage Flasks / Racks Gas storage racks are required to store oxygen and mixed-gas for diving operations. Responses with individual bottles and full solutions are acceptable as well as options that meet the goals of both gas storage systems at under the combined target footprint. Must use currently approved DOT cylinders.

Please include wet volume and working pressure in responses.

Storage Pressure • 4350-8000 psig HeO2

• 3000-6000 psig O2

Compatibility • Compatible with 100% O2 at the maximum storage pressure

• Designed for long term use in a marine environment

Safety Designed in accordance with ASTM standards Minimum Rack Gas Storage 4500 scf

Rack Manifold The rack must be divisible into two or more smaller banks within the rack

Rack Inlets Threshold: Port for a booster pump or external gas supply.

Objective: 2 Ports, accessible from different locations.

Rack Outlets

• Connection to the Gas Control Console

• Regulated SCUBA charging port o Robust, max pressure capable, flexible SCUBA charging hose

Rack Front Panel

• Pressure Gauges for each bank with calibration ports

• Valves to direct inputs to primary or secondary

• Valves to direct primary or secondary to outlets

Rack Size

• Must Supply Footprint of Suggested Design

• Maximum Height: 71 3/16”

• Maximum Width: 77 9/16”

• Maximum Length: 220 11/16”

Rack Transport

• Forklift lift points

• Crane lift points

• Attachment point for shipboard deployment

Air Storage Flasks / Racks Air storage racks are required to store air for diving operations. Responses with individual bottles and full solutions are acceptable as well as options that meet the goals of both gas storage systems at under twice the target footprint. Must use currently approved DOT cylinders. Please include wet volume and working pressure in responses.

Storage Pressure 4350-8000 psig

Compatibility Materials used must be compatible with 21% O2 at the maximum storage pressure

Safety Designed in accordance with ASTM standards Minimum Rack Gas Storage 4500 scf

Rack Manifold The rack must be able to be manifolded into 2 separate banks of bottles so that one can be filled while the other is used.

Rack Inlets Port for an air compressor

Rack Outlets

• Connection to the Gas Control Console

• Connection to a recompression chamber

• Regulated SCUBA charging port o Robust, max pressure rated, flexible SCUBA charging hose

Rack Front Panel

• Pressure Gauges for each bank with calibration ports

• Valves to direct inputs to primary or secondary

• Valves to direct primary or secondary to outlets

Rack Size

• Must Supply Footprint of Suggested Design

• Maximum Height: 71 3/16”

• Maximum Width: 77 9/16”

• Maximum Length: 220 11/16”

Rack Transport

• Forklift lift points

• Crane lift points

• Attachment point for shipboard deployment

Air Compressor

A diesel or electric air compressor is required to fill the air gas storage flasks with breathable diving air.

Outlet Pressure 4350-8000 psig

Minimum Flow Rate 25 scfm Power Diesel or Electric

Oxygen Booster Pump

A booster pump is needed to fill the O2 Gas Storage Flasks to their 5000psig maximum.

Outlet Pressure 3000-6000 psig Compatibility Materials used must be compatible with 100% O2 at 5000 psig

Minimum Compression Ratio 10:1

HeO2 Booster Pump A booster pump is needed to fill the HeO2 Gas Storage Flasks to their 5000 psig maximum.

Outlet Pressure 4350-8000 psig Compatibility Materials used must be compatible with ≤ 50% O2 at 5000 psig

Minimum Compression Ratio 10:1

Gas Mixer A gas mixer is needed to provide HeO2 mixes pre-mixing bottles which will later be used for diving, decompression, and treatment

Input Gases • Helium

• Oxygen

Accuracy 0.5% Output Gases 0-50% Oxygen

Gas Control Console

A Gas Control Console is required to facilitate gas delivery to three divers from the Gas Storage Flasks.

The console goal is to have a minimal footprint and be easy to understand for a new user.

Input gases

• Air

• HeO2 0-20% O2

• HeO2 20-50% O2

• O2

Minimum Input Pressures 5000-8000 psig

Outlet Pressures

• Air:

• HeO2 0-20% O2:

• HeO2 20-50% O2:

• O2:

0-400 psig (Threshold) 0-1000 psig (Objective)

Outputs The system must be able to output any of the input gases to three diver worn UBAs.

Communication & Lighting Systems

A new communication system is desired to better communicate information between the divers and topside. Responses for the diver side of the communications system may include replacements for current commercially available FFM and Stainless Steel Dive Helmet communication systems but otherwise must be compatible with them. Complies with IMCA D045.

Signal Type Digital

Audio Inputs • One microphone for each FFM/Stainless Steel dive helmet

• Microphones for three separate topside locations

Audio Outputs

• One audio output (speakers or headphones) for each of the three FFMs and Stainless Steel Dive Helmets

• Simultaneous headset and loudspeaker outputs at three separate topside locations

Video Inputs A camera mountable to the FFM and Stainless Steel Dive Helmet, one camera for each of the three FFMs/helmets.

Video Outputs Single monitor displaying and recording all three video feeds in real-time.

Light(s) A light/lights mountable to each of the three FFMs/Stainless Steel Dive Helmets. Ideally powered topside but battery powered options will be considered.

Connections One 600’ cable to connect the diver’s audio, video, and light (unless light is otherwise powered) to topside. Three 600’ cables total, one for each diver.

Pressure The camera, diver side audio, and the communication cable must be pressure rated to 380 fsw. Equipment will be pressure tested to 1.5 times the rated depth.

Topside Monitor

A Topside Monitor is required to track critical diver information and relay it real-time to topside.

Information tracked

• Depth (fsw)

• Diver Location

• Oxygen Partial Pressure

• Gas Delivery (scfm) (objective)

• CO2 (objective)

Divers Information for three divers will need to be

• monitored (threshold)

• recorded (objective)

Display Single display for all tracked information

Subsea Systems Underwater Breathing Apparatus (UBA)

A proposed goal is for a semi-closed or closed-circuit UBA is to function utilizing surface supplied mixed-gasses for the unit’s primary open and closed-circuit gas supplies diving at a maximum of 380 fsw. The UBA is also has a goal to function as a self-contained semi-closed or closed-circuit EBS system should surface gas become unavailable. Other UBA goals are to compensate for diving at altitude and to be as robust, small, and light as possible.

Type Semi-closed or closed-circuit rebreather Operational Temperatures 28 °F to 99 °F

Human Interface Compatible with FFMs and Stainless Steel Dive Helmets

Maximum Operating Depth 380 fsw Minimum Scrubber Duration 80 minutes at 380 fsw at 28°F

Maximum Resistive Effort

Passes NEDU breathing standards at 300 fsw on Heliox and 190 fsw on air at the following work rates.

Rebreather mode: 62.5 RMV Open-circuit mode: 40 RMV

Maximum Average Inspired CO2 Average Inspired CO2 is less than 2% surface equivalent value (SEV) at 22.5, 40, and 62. RMV.

Oxygen Fraction ≤50% O2

Wet-mateable Off-board Gas QC

Has the ability to supply open-circuit gas and supplement all on board gas supplies by connecting and disconnecting underwater to various gas sources.

On Board (UBA) Bottle Duration On Board (UBA) gas supply will last:

Threshold: 30 minutes at 380 fsw and 40 RMV Objective: 4 hours at 380 fsw and 40 RMV

Diving Umbilical

A Diving umbilical is required to move gas from the surface to the diver. The goal is to reduce the weight/footprint over current umbilical while still remaining durable.

Maximum Inner Diameter 3/8” Length 600’

Connections 37° Flare Minimum Pressure Rating 600psi

Diving Thermal Protection A Diver Thermal Protection system is required to protect the divers from extreme temperature conditions.

Minimum Operating Water Temperature 28 °F Maximum Operating Depth 380 fsw

Respond with the following documentation:

1. Technical literature with complete description and specifications illustrating the ability of the apparatus to meet the above characteristics in this request for information.

2. Estimated unit cost for quantities of 5, 50, and 100.

3. Estimated quantity of units currently fielded.

4. Estimated preventative maintenance costs for 1 and 2 year periods to include replacement parts, o-rings, seals, etc. for 5, 50, and 100 units.

This is not a solicitation, nor will a solicitation package be issued because of this announcement.

If a solicitation is developed, it will be assigned a formal Request for Proposal (RFP) number, and the announcement will be published in the sam.gov Government Point of Entry. Responses requested no later than 12 July 2024. Direct expression of interest as well as required documentation should be addressed in writing to Lauren Hunter, E-mail lauren.m.hunter9.civ@us.navy.mil

U.S. Navy General Specification for Diving and Manned Hyperbaric

Systems

REVISION 2

DEPARTMENT OF THE NAVY

NAVAL SEA SYSTEMS COMMAND

SUPERVISOR OF DIVING

AND SALVAGE

WASHINGTON, DC 20376

DISTRIBUTION STATEMENT A: THIS DOCUMENT HAS BEEN APPROVED FOR PUBLIC RELEASE AND

SALE; ITS DISTRIBUTION IS UNLIMITED.

SUPERSEDES NAVSEA TS500-AU-SPN-010, Dated August 23, 2006, Which Shall Be Destroyed In Accordance With Applicable Security Regulations.

TS500-AU-SPN-010

REVISION 2, 10 FEB 2023

0910-LP-119-7775

i

THIS PAGE INTENTIONALLY LEFT BLANK

ii

FORWARD

The express purpose of Revision 2 of this technical publication is to authoritatively establish technical requirements for design, fabrication and repair of U.S. Navy (USN) diving and hyperbaric systems.

Unlike the previous issue of this document, a cursory review of this revision will reveal a complete and comprehensive re-organization. Technical and editorial changes have been made throughout and reviewers are encouraged to read this document in its entirety. Every effort has been made to ensure all referenced support documents are correct and current as of the date of this issue. However, despite these best efforts, reviewers are encouraged to always be on the look-out for changes. Requirements change as technology evolves and the ability to improve designs continues to mature and change. Given this fact, the collection of comments for future revisions starts with the date of issue of this revision.

Those who review and use this manual are not to interpret the requirements contained within. Questions and comments regarding the contents of this manual, or the design, fabrication and repair process in general, should be submitted by email to Naval Sea Systems Command (NAVSEA) at usn.washington.comnavseasyscomdc.mbx.sea-00c3@us.navy.mil. Certification related questions can be sent to usn.washington.comnavseasyscomdc.mbx.sea- 00c4@us.navy.mil.

Richard Schoenwiesner Director, Diving Division

(SEA 00C3)

Sal M. Suarez, CAPT, USN Supervisor of Salvage & Diving, USN Director of Ocean Engineering mailto:usn.washington.comnavseasyscomdc.mbx.sea-00c3@us.navy.mil mailto:usn.washington.comnavseasyscomdc.mbx.sea-00c4@us.navy.mil mailto:usn.washington.comnavseasyscomdc.mbx.sea-00c4@us.navy.mil iii

THIS PAGE INTENTIONALLY LEFT BLANK

iv

TABLE OF CONTENTS

1-1 PURPOSE

1-2 SCOPE 1

1-3 BIBLIOGRAPHY

1-4 DEFINITIONS

1-5 ABBREVIATIONS

1-6 ROLES AND RESPONSIBILITIES

1-6.1 ACQUISITION/PROGRAM MANAGER (PM)

1-6.2 TECHNICAL WARRANT HOLDER (TWH)

1-6.3 SYSTEM CERTIFICATION AUTHORITY (SCA)

1-6.4 DESIGNER

1-6.5 BUILDER

1-6.6 DEPOT MAINTENANCE FACILITY

1-6.7 IN-SERVICE ENGINEERING AGENT (ISEA)

1-6.8 SYSTEMS ENGINEER (SE)

2-1 DESIGN PROCESS

2-1.1 SYSTEMS ENGINEERING PLAN (SEP)

2-1.2 CONFIGURATION MANAGEMENT

2-1.3 TECHNICAL REVIEWS

2-1.4 SYSTEM SAFETY PROGRAM

2-1.5 SCOPE OF CERTIFICATION (SOC) DEFINITION

2-1.6 HUMAN SYSTEMS INTEGRATION (HSI)

2-1.7 RELIABILITY AND MAINTAINABILITY

2-1.8 COMMAND AND CONTROL (C2)

2-1.9 DESIGN PARAMETERS

2-1.10 INTEROPERABILITY

2-2 GENERAL DESIGN REQUIREMENTS

2-2.1 DIVERS LIFE SUPPORT SYSTEM (DLSS)

2-2.2 DESIGN CALCULATIONS

2-2.3 DRAWINGS

2-2.4 MATERIALS

2-2.5 PIPING SYSTEM AND COMPONENTS

2-2.6 PRESSURE VESSELS

2-2.7 WELD DESIGN

2-2.8 ELECTRICAL SYSTEMS

2-2.9 COMMUNICATION SYSTEMS (COMMS)

2-2.10 ENVIRONMENTAL CONDITIONING

2-2.11 FIRE SAFETY/SUPPRESSION REQUIREMENTS

2-2.12 COMPRESSORS

2-3 DESIGN REQUIREMENTS FOR SPECIFIC TYPES OF SYSTEMS

2-3.1 BREATHING APPARATUS

2-3.2 SURFACE SUPPLIED DIVING SYSTEM (SSDS)

2-3.3 RECOMPRESSION CHAMBER

2-3.4 SATURATION DIVERS LIFE SUPPORT SYSTEM (DLSS)

2-3.5 HANDLING SYSTEMS

v

2-4 SPECIFIC DESIGN CONSIDERATIONS

2-4.1 NAVAL ARCHITECTURE DESIGN

2-4.2 TRANSPORTABILITY

2-5 DESIGN DOCUMENTATION

2-5.1 DESIGN PARAMETERS

2-5.2 DESIGN ANALYSIS

2-5.3 DESIGN CALCULATIONS

2-5.4 SYSTEM DRAWINGS

2-5.5 JUSTIFICATION OF MATERIALS AND NEW APPLICATIONS

2-5.6 TOXIC AND FLAMMABLE SAFETY ANALYSIS

2-5.7 HAZARD ANALYSIS

2-5.8 OPERATION AND EMERGENCY PROCEDURES (OPS/EP)

2-5.9 DESIGN VERIFICATION AND VALIDATION

2-5.10 COMMAND AND CONTROL (C2) DOCUMENTATION

3-1 ADMINISTRATIVE REQUIREMENTS

3-1.1 FABRICATION REVIEWS

3-1.2 DEVIATIONS/CHANGES

3-1.3 CONFLICTS

3-2 QUALITY ASSURANCE (QA)

3-2.1 SCOPE OF CERTIFICATION (SOC)

3-2.2 CONTROLLED WORK PROCEDURES (CWP)

3-2.3 RECORDS

3-3 PROCUREMENT

3-3.1 GENERAL

3-3.2 PURCHASE DOCUMENTS

3-3.3 RECEIPT INSPECTION

3-4 MATERIAL

3-4.1 GENERAL

3-4.2 TRACEABILITY

3-5 FABRICATION PROCESSES

3-5.1 PIPING SYSTEM FABRICATION

3-5.2 PRESSURE VESSELS

3-5.3 WELDING

3-5.4 BRAZING

3-5.5 ELECTICAL/ELECTRONIC SYSTEMS

3-5.6 CLEANING

3-6 TESTING

3-6.1 GENERAL

3-6.2 SYSTEM TESTING PROGRAM

3-6.3 TEST CATEGORIES

3-6.4 ELECTRICAL TESTING

3-6.5 STRENGTH TESTING

3-6.6 VALVE SEAT TIGHTNESS TESTING

3-6.7 JOINT TIGHTNESS TEST

3-6.8 PRESSURE DROP TESTS

3-6.9 AIR PURITY TEST

3-6.10 NON-METALLIC OFF-GAS TESTING

3-6.11 VERIFICATION OF AS-BUILT STRENGTH (PROOF TEST) FOR EXTERNALLY

LOADED PRESSURE HULLS/VESSELS AND HARD STRUCTURES

3-6.12 TESTING PARAMETERS FOR PERMANENTLY OR TEMPORARILY

MOUNTED EXTERNAL IMPLODABLE AND EXPLODABLE ITEMS

3-6.13 TESTING PARAMETERS FOR EXPLODABLE ITEMS DUE TO

DECOMPRESSION

3-6.14 TEST-GAUGES/INSTRUMENTATION

vi

3-6.15 TESTING OF LIFTING POINTS AND RIGGING

3-6.16 DIVER HANDLING SYSTEM TESTING REQUIREMENTS

3-6.17 INCLINING EXPERIMENTS AND TRIM DIVES FOR SUBMERSIBLES AND

SUBMERGED HABITATS

3-6.18 SOFTWARE TESTING

3-7 INTEGRATED SYSTEM TESTING

3-7.1 GENERAL

3-8 SHIPPING

3-8.1 GENERAL

4-1 INTRODUCTION

4-1.1 PURPOSE

4-2 GENERAL REQUIREMENTS

4-2.1 REPAIR AND MODIFICATION NOTIFICATION AND APPROVAL

4-2.2 OPERATION AND MAINTENANCE APPROVAL

4-2.3 LIFE-CYCLE MANAGEMENT

4-2.4 SHIP ALTERATIONS (SHIPALTS)

4-2.5 ENGINEERING CHANGE PROPOSAL (ECP)

E-1 INTRODUCTION

E-1.1 SCOPE

F-1 GENERAL

G-1 GENERAL

J-1 INTRODUCTION

J-2 DEFINITIONS

J-3 IMPLODABLE ITEMS

J-3.1 EXPLODABLE ITEMS

J-3.2 EXPLODABLE ITEMS DUE TO DECOMPRESSION

J-3.3 PRESSURE VESSELS

J-4 DETERMINATION OF WHETHER OR NOT AN EXPLODABLE OR IMPLODABLE IS

CRITICAL OR NONCRITICAL

J-5 TESTING NECESSARY FOR CRITICAL IMPLODABLE/EXPLODABLE VOLUMES .. 274

J-6 TEST RECORD OBJECTIVE QUALITY EVIDENCE (OQE) REQUIRED FOR CRITICAL

IMPLODABLE AND EXPLODABLE VOLUMES

J-9 EXEMPTIONS TO TESTING CRITICAL IMPLODABLE/EXPLODABLE VOLUMES ... 276

K-1 INTRODUCTION

K-2 DESCRIPTION AND ORIENTATION

K-3 TEST PROCEDURE

K-4 POROUS OR VENTED COMPONENTS

L-1 FINITE ELEMENT ANALYSIS (FEA) MODELING REQUIREMENTS

L-1.1 GENERAL REQUIREMENTS

vii

L-1.2 SHELL ELEMENTS

L-1.3 SOLID ELEMENTS

L-2 FINITE ELEMENT ANALYSIS REVIEW CHECKLIST

viii

FIGURES

Figure 1: Systems Engineering Figure 2: Relation of Physiological Effects of Carbon Dioxide Concentration and

Exposure Period Figure 3: Relation of Physiological Effects of Carbon Dioxide Concentration and

Exposure Period Figure 4: Correct Valve Installation

Figure F 1: Non-Metallic Material

TABLES

Table 1: Allowable Oxygen Partial Pressure by System Type Table 2: Seals Table 3: Lubricating Greases and Oils Table 4: Color Code and Component Designation for DLSSs Table 5: O-Ring Cross Reference Table Table 6: Recommended Thickness of Piping Prior to Bending Table 7: Afloat and Portable Pipe Support Spacing Table 8: Diver Life Support System (DLSS) Gauge Accuracy Requirements Table 9: Gauge Accuracy Grades Table 10: Recommended Illumination Levels for Various Task Grades Table 11: Design Factors for Rigging Table 12: Sea State Definitions Table 13: Sample Table of Contents for Material Certification Data Book (non-

PVHO)

Table 14: Sample Table of Contents for Material Certification Data Book (PVHO only) Table 15: Test Accuracy

Table 17: Insulation Resistance Correction Table Table 18: Testing Requirements – Load Bearing Components Table 19: Testing Requirements – Hydraulic System Components Table 20: Testing Requirements – Electrical System Components

Table F 1: Applicable Documents Table F 2: Acronyms and Abbreviations file://naeawnydfs101v.nadsusea.nads.navy.mil/USER107$/mary.savat/00C4/Bob%20Bauer/Gen%20Spec/Main%20Documents/05-03-2021%20Gen%20Spec%20Draft%20-%20comments.docx#_Toc71808839 file://naeawnydfs101v.nadsusea.nads.navy.mil/USER107$/mary.savat/00C4/Bob%20Bauer/Gen%20Spec/Main%20Documents/05-03-2021%20Gen%20Spec%20Draft%20-%20comments.docx#_Toc71808820

REVISION 2 NAVSEA TS500-AU-SPN-010

PART 1 INTRODUCTION

1-1 PURPOSE

The purpose of this specification is to establish the technical requirements for the design, fabrication and repair of diving and hyperbaric systems for use in the USN. It provides an overview of how a divers life support system (DLSS) shall be developed. Information in this specification is from various sources, including both commercial & government/military references.

1-2 SCOPE

This design specification applies to all USN diving and manned hyperbaric systems under the Technical Authority (TA) of the Supervisor of Salvage and Diving (SUPSALV), NAVSEA 00C. USN diving and manned hyperbaric systems include all surface-supplied DLSSs, saturation DLSSs, manned recompression chamber systems, diving bells, and handling systems used for maneuvering DLSSs or personnel during manned operations.

Throughout this document, where the term "DLSS" is used, it is meant to include manned hyperbaric systems. This document is not intended to impose rigid procedures for design, nor discourage initiative and innovation in the use of new methods, components or materials.

1-3 BIBLIOGRAPHY

References that may be useful in DLSS design are listed in Appendix A.

Unless otherwise indicated, the most recent issue or revision of each shall be used.

1-4 DEFINITIONS

Definitions applicable to this document are provided in Appendix B.

1-5 ABBREVIATIONS

Abbreviations used in this document are provided in Appendix C.

1-6 ROLES AND RESPONSIBILITIES

1-6.1 ACQUISITION/PROGRAM MANAGER (PM)

The Acquisition/Program Manager (PM) is a government employee who is the designated individual with the responsibility for and authority to accomplish the project objectives for the development, production, and sustainment to meet the user’s operational needs. The PM is accountable for the overall cost, schedule, and performance of the project. They exercise the decision-making powers and oversight throughout the project.

1-6.2 TECHNICAL WARRANT HOLDER (TWH)

The Technical Warrant Holder (TWH) is the USN engineer and recognized technical expert in their field across specific technical domains. The TWH is the independent technical conscience for the USN to make sure systems being designed, produced and delivered to the fleet are as technically sound and as safe as possible. The TWH supports the PM, providing best value engineering and technical products.

1-6.3 SYSTEM CERTIFICATION AUTHORITY (SCA)

The System Certification Authority (SCA) provides an objective, third-party review of the design, fabrication, testing, and operating and maintenance (O&M) procedures of all USN owned or operated manned diving and hyperbaric systems. The SCA is designated via Office of the Chief of Naval Operations Instruction (OPNAVINST) 3150.27, U.S. Navy Diving Program. Certification of DLSSs under the cognizance of the SCA is conducted in accordance with (IAW) NAVSEA SS521-AA-MAN-010, U.S.

Navy Diving and Manned Hyperbaric Systems Safety Certification Manual.

The PM works with the SCA to ensure detailed technical reviews of the system design are conducted and formally documented.

1-6.4 DESIGNER

An individual or organization responsible for the design of the DLSS. The designer is responsible and liable for the safe design of the DLSS that, meets or exceeds contract specifications.

1-6.5 BUILDER

An individual or organization responsible for the fabrication and assembly of a DLSS IAW with the design specifications. The builder is responsible and liable for the safe delivery of a complete DLSS that meets contract specifications and is certifiable by the SCA.

1-6.6 DEPOT MAINTENANCE FACILITY

Facility that has the infrastructure to perform major overhauls or a complete rebuild of parts, assemblies, subassemblies, and end items, including the manufacture of parts, modification, testing, and reclamation, as required.

1-6.7 IN-SERVICE ENGINEERING AGENT (ISEA)

Provide technical services to the PM, the TWH and the Fleet. In-Service Engineering Agents (ISEAs) provide analysis, develop technical alternatives and assess performance and risk mitigations. They are available to assist the design and certification of systems, construction, production or integration for in-service systems.

1-6.8 SYSTEMS ENGINEER (SE)

The Systems Engineer (SE) refers to the Program Lead SE, the Chief Engineer or Lead Engineer responsible for SE processes and who plan, conduct and/or manage SE activities in the program. The SE balances the conflicting design constraints of cost, schedule, and performance while maintaining an acceptable level of risk. The SE should possess the skills, instincts and critical thinking ability to identify and focus efforts on the activities needed to enhance the overall system effectiveness, suitability, survivability and sustainability.

PART 2 DESIGN

Part 2 provides guidance, rules and requirements for use by experienced engineers to design a DLSS for USN use. The overarching purpose of a DLSS is to safely take personnel to a specified depth, maintain life, and safely return the personnel to the surface. Missions that involve diving operations may take hours or, if saturation diving is involved, days or weeks. It is imperative that any DLSS designer must understand the special hazards associated with diving and hyperbaric environments. Ultimately, the final responsibility for all aspects of a safe design lies with the DLSS designer and cannot be delegated to any manual or textbook.

2-1 DESIGN PROCESS

2-1.1 SYSTEMS ENGINEERING PLAN (SEP)

Systems engineering ensures the effective development and delivery of capability through the implementation of a balanced approach with respect to cost, schedule, performance and risk, using integrated, disciplined and consistent activities and processes (see Figure 1). IAW the Defense Acquisition Guidebook (DAG), the PM and SE should develop a tailored Systems Engineering Plan (SEP) which identifies the most effective and efficient path to deliver a capability, from identifying user needs and concepts through delivery and sustainment.

Figure 1: Systems Engineering

The SEP is a living document that details the execution, management, and control of the technical aspects of a DLSS acquisition from conception to disposal. Event-driven technical reviews and audits, as described later in this section, assess program maturity and determine the status of the technical risks associated with cost, schedule and performance goals.

The SEP is updated as needed to reflect technical progress achieved and to reflect changes in the technical approaches stemming from the findings and results of the technical reviews, program reviews, acquisition milestones, or other program decision points.

Depending on the complexity of the DLSS an effective SE may require the development of the following key documents:

a. Initial Capabilities Document (ICD).

b. Capability Development Document (CDD).

c. Concept of Operations (CONOPS).

d. Acquisition Strategy.

e. Risk Management Plan (RMP).

f. Configuration Management Plan (CMP).

g. Integrated Master Plan (IMP).

h. Integrated Master Schedule (IMS).

i. Test and Evaluation Master Plan (TEMP).

j. Draft System Specifications.

As the program’s blueprint for the conduct, management and control of all technical activities, the SEP fosters comprehensive decision making during the technical planning process and communicates objectives and guidance to program personnel and other stakeholders. As the system matures and issues arise, the PM and SE should consistently look for root cause(s) and implement corrective actions in order to enable programmatic and technical success. Modifications to the SE processes and SEP may be required because of root cause and corrective action analysis and implementation.

The PM may opt to provide the SEP with the Request for Proposal (RFP) and require the contractor deliver a Systems Engineering Management Plan (SEMP) that is consistent with the SEP. The SEMP is the contractor-developed plan for the conduct, management and control of the integrated engineering effort. The SEMP should define the contractor technical planning and how it is accomplished from the contractor perspective, and articulates details of their processes, tools and organization.

2-1.2 CONFIGURATION MANAGEMENT

Configuration Management (CM) is defined as a management process for establishing and maintaining consistency of a product’s performance, functional, and physical attributes with its requirements, design and operational information throughout its life. CM contains the documentation that describes what is supposed to be designed, what is being designed, what has been designed, and what modifications have been made to what was designed.

A CM program ensures that designs are traceable to requirements, that change is controlled and documented, that interfaces are defined and understood, and that there is consistency between the product and its supporting documentation. The objectives of CM are to identify and document the characteristics of a Configuration Item (CI); to control changes to these characteristics; to provide information on the status of change action; and to audit and review the item for compliance with contractual and identification requirements.

CM comprises four interrelated efforts: Identification, Control, Status Accounting, and Audits as described in the following sections. NSW S13- CMP-01, Fleet Diving Systems CMP provides organizational and managerial guidance and direction to all Fleet DLSS contractors and government agencies in meeting CM procedures and authorizations unique to the Fleet DLSS equipment. If alternative CMPs are required, the designer shall provide a copy of the applicable CMP for approval to the PM at the preliminary design review (PDR).

2-1.2.1 Identification of Configuration Baselines and Specifications Configuration Identification consists of the documentation of the formally approved baselines and specifications. The configuration baselines are fixed reference configurations established by defining and recording the approved configuration documentation for a System or CI at a milestone event or at a specified time. Major configuration baselines known as the functional baselines (FBL), allocated baselines (ABL), and product baselines (PBL) as well as the developmental configuration, are associated with milestones in the life cycle of a CI.

Each of these major configuration baselines is designated when the given level of the CI's configuration documentation is deemed to be complete and correct, and needs to be formally protected from unwarranted and uncontrolled change from that point forward in its life cycle.

Configuration documentation identifies the functional and physical characteristics of the CIs. It is developed, approved, and maintained through the evolutionary baselines of the DLSS design.

2-1.2.1.1 Functional Baseline (FBL) The FBL consists of the initial documentation describing a system's functional, interoperability, and interface requirements and the verification required to demonstrate the achievement of those specified characteristics. The FBL consists of the initially approved technical documentation for a system or top level CI as set forth in the system specification prescribing:

a. All necessary functional characteristics.

b. The verification/tests required to demonstrate achievement of the specified functional characteristics.

c. The necessary interface and inter-operability characteristics with associated CIs, other system elements, and other systems.

d. Identification of lower level CIs, if any, and the configuration documentation for items (such as items separately developed or currently in the inventory) which are to be integrated or interfaced with the CI.

e. Design constraints, such as envelope dimensions, component standardization, use of inventory items and integrated logistics support policies.

f. Specific designation of the functional characteristics of key CIs.

The FBL is established after the System Requirements Review (SRR) and controlled by the PM. From a contractor's point of view, a FBL, whether formally established or not, is always in place at the inception of the design and is represented by whatever documentation is included or referenced by the contract to define the technical/performance requirements that the contractor's product is obligated by the contract to meet.

2-1.2.1.2 Allocated Baseline (ABL) The ABL is the currently approved documentation describing a CI’s functional, interoperability, and interface requirements and the verification required to demonstrate the achievement of those specified characteristics. The ABL consists of the current approved performance oriented documentation governing the development of a CI, in which each specification:

a. Defines the functional and interface characteristics that are allocated from those of the system or higher level CI.

b. Establishes the verification required to demonstrate achievement of its functional characteristics.

c. Delineates necessary interface requirements with other associated CIs.

d. Establishes design constraints, if any, such as component standardization, use of inventory items, and integrated logistics support requirements.

The ABL is established after the PDR and is controlled by the designer. The requirements in the specification are the basis for the contractor's design of the CI; the quality assurance (QA) provisions in the specification form the framework for the qualification-testing program for the CI. The ABL for each CI is documented in an item performance (or detail) specification, generally referred to as a development specification.

2-1.2.1.3 Development Configuration The Development Configuration is the contractor's design and associated technical documentation that defines the contractor's evolving design solution during development of a CI. The developmental configuration for a CI consists of that contractor internally released technical documentation for hardware and software design that is under the developing contractor's configuration control until the establishment of the PBL.

Contractor implementation of the FBL and ABL requirements involves the creation, and release of engineering documentation that incrementally defines the configuration of the specific product. The developmental configuration represents the contractors detailed design solution. It may or may not include a detail specification for the product. The contractor is responsible for the configuration control of the developmental configuration and may iteratively design, release, prototype and test until the functional and allocated requirements are satisfied.

The developmental configuration will ultimately include the complete set of released and approved engineering design documents, such as the engineering drawings and associated lists for hardware and the software, interface and database design documents for software. By reference within this documentation, it also includes test and verification documents.

When establishing a CM program, the designer should follow the guidance in NAVSEAINST 4130.12, Configuration Management Policy and Guidance. Other useful references that may also be consulted are American National Standards Institute (ANSI)/Electronics Industries Alliance (EIA)-649, National Consensus Standard for Configuration

Management, MIL-HDBK-61, Configuration Management Guidance, International Organization for Standards (ISO) 10007, Quality Management Systems – Guidelines for Configuration Management and Secretary of the Navy Instruction (SECNAVINST) 4130.2, Department of the Navy Configuration Management Policy.

2-1.2.1.4 Product Baseline (PBL) The PBL is the initially approved documentation describing all of the necessary functional and physical characteristics of the CI. It also describes the selected functional and physical characteristics designated for production acceptance testing and tests necessary for support of the CI.

The PBL documentation includes the complete set of released and approved engineering design documents including engineering models, engineering drawings and associated lists for hardware. The software, interface and database design documents for software should also be included in the PBL. The PBL may include the 2-D or 3-D engineering model of a hardware product. For software the PBL should include a representation of the source code. It also includes, by reference, the material and process specifications invoked by the engineering documentation.

The PBL is established after the Critical Design Review (CDR) and controlled by the PM.

2-1.2.2 Configuration Control Configuration control is how the DLSS’s (and its associated CIs) change control process is executed and managed after the formal establishment of its baseline. It consists primarily of a change process that formalizes documentation and provides a management structure for change approval. NSW S13-CMP-01 provides organizational and managerial guidance and direction to all Fleet DLSS contractors and government agencies in meeting CM procedures and authorizations unique to the Fleet DLSS equipment.

2-1.2.3 Configuration Status Accounting (CSA) Configuration Status Accounting (CSA) is the recording and reporting of the information that is needed to manage the configuration effectively, including a list of approved documentation, status of proposed changes, and the configuration of all the system. IAW MIL- HDBK-61 and ANSI/EIA-649, a CSA system shall be established and maintained throughout the life-cycle of a CI, and related technical and logistics support products. This information is essential for providing a unique and positive identification of a CI and for entering in all technical and logistics documents related to it. CSA is the method used to track and record changes to the configuration baseline and is the management tool for ensuring that all related tasks resulting from baseline changes are accomplished.

The designer is encouraged to use commercial electronic engineering document management software that allows transfer and access to configuration documentation. The use of MIL-STD-974, Contractor Integrated Technical Information Services (CITIS); Defense Acquisition Deskbook, Section 3.7, Computer-aided Acquisition and Logistic Support; and appropriate Integrated Digital Environment to provide the USN online access to or delivery of programmatic and technical data in digital form is required unless waived by the PM. The Defense Acquisition Deskbook is an automated repository of information that consists of an electronic desk reference set, a tool catalogue, and a forum for the exchange of information.

2-1.2.4 Configuration Audits Verification of the functional and physical requirements called out in the specifications is an integral part of CM. Configuration Audits are used to verify a system and its components’ conformance to their configuration documentation. Functional Configuration Audits (FCA) are used to verify that the actual performance of the CI meets the specification requirements. Physical Configuration Audits (PCA) is a formal examination of a production representative unit against the PBL.

These types of audits are normally performed during the Fabrication phase of the DLSS (see Part 3).

2-1.3 TECHNICAL REVIEWS

The design progress and maturity is assessed at technical reviews, which are key event-driven points, conducted after certain levels of development have been achieved. The design is compared to pre-established exit criteria for the particular event to determine if the appropriate level of maturity has been achieved. They are utilized to check design maturity, review technical risk and determine whether to proceed to the next development level. Formal technical reviews are to verify that problems have been solved and are not considered a problem solving event.

The reviews briefly summarized below are based on a complex DLSS project, requiring significant technical evaluation. There may be a need to tailor the design assessment activities as appropriate for a particular DLSS. There may be cases where system technical maturity is more advanced than typical (i.e., based on a previous program) which may allow for the merging or elimination of certain events. The technical baseline (including the FBL, ABL, and PBL) established at the conclusion of certain technical reviews inform all other program activities. The designer and the PM shall agree upon the tailoring of these events, however baselines must be developed sequentially as they must build on each other.

Details on roles and responsibilities, entrance/exit criteria and products of the following events are found in the DAG and should be outlined and tailored for the design in the SEP and SEMP.

2-1.3.1 System Requirements Review (SRR) This review determines the adequacy of the designer’s efforts in translating the PM’s requirements into system specific technical requirements in order to meet the performance requirements and the standards of the DLSS. Risks shall be well understood and mitigation plans shall be in place. The following documentation should be included to assist in a successful review:

a. System Operations Requirements.

b. Draft System Specification and draft Performance Item

Specifications.

c. Functional Analysis (top level block diagrams).

d. Feasibility Analysis (technology assessments as required).

e. System Maintenance Concept.

f. Overall System Design Criteria (reliability, logistics, etc.).

g. SEP.

h. TEMP.

i. Draft Top-Level Technical Performance Measurements.

j. System design documentation (layout, conceptual drawings, selected suppliers, etc.).

k. Trade Studies.

The SRR confirms that the system-level requirements are sufficiently well understood to permit the designer to establish an initial system level FBL. Once the FBL is established, the functional, performance and physical attributes of the items below system level can be defined and allocated to the physical subsystems or CIs that will perform the functions.

2-1.3.2 System Functional Review (SFR) This review determines the adequacy of the designer’s engineering efforts in defining and optimizing the major subsystems or CIs, with associated functionality and performance requirements, that compose the system. This review shall result in two major products which will define the FBL and the draft ABL: the final System Performance Specifications and the draft Performance Specifications for the subsystems or CIs. This review signifies the that the system has passed from concept to a well-defined system design. The system functional review (SFR) shall include the assessment of the following items:

a. Verification that the System Specification reflects the PM’s requirements.

b. Functional Analysis and allocation of requirements to subsystems/CIs.

c. Draft CI Performance Specifications.

d. Design data that defines the overall system.

e. Verification that the risks associated with the system design are at acceptable levels for engineering development.

f. Verification that the design selections have been optimized.

g. Any supporting Analyses and Plans are complete where appropriate (logistics, human systems integration (HSI), etc.).

h. Technical Performance Measurement data and analyses.

i. Plans for evolutionary design and development are in place and that the system design is modular and open.

During the SFR the system level FBL must be approved by the PM as the governing technical requirement before proceeding to further technical development, which allows for the engineering design and development of the CIs. The PM will take control and manage the system FBL following the completion of the SFR. Once the FBL is established, the functional, performance and physical attributes of the items below system level can be defined and allocated to the physical subsystems or CIs that will perform the functions.

Work then proceeds to complete the definition of the subsystems or CIs in terms of function, performance, and interface requirements.

Reviews may be held for the design requirements at the subsystem levels in order to verify that the lower level design requirements will result in an acceptable detailed design of the system. The establishment of the CI design requirements represents the ABL for the system.

2-1.3.3 Preliminary Design Review (PDR) This is a formal technical review of the basic design approach and is typically held when 15% of the production drawings are released.

Using the FBL as a governing requirement, a preliminary design is expressed in terms of design requirements for subsystems and CIs of the DLSS. This preliminary design sets forth the functions, performance, and interface requirements that will govern design of the items below system level. The PDR shall include the assessment of the following items:

a. Subsystem/CI Performance Specifications.

b. Draft Item Detail, Process, and Material Specifications.

c. CMP.

d. Scope of Certification (SOC) boundaries (must be approved by the

PM).

e. Design data defining major subsystems, equipment, software, and other system elements.

f. Analyses, reports, maintenance and reliability analyses, trade studies, logistics support analysis data, and design documentation.

g. Technical Performance Measurement data and analysis.

h. Engineering breadboards, laboratory models, test models, mockups, and prototypes used to support the design.

i. Supplier data describing specific components.

The SOC boundaries must be reviewed and approved by the NAVSEA 00C3 PM and NAVSEA 00C4 SCA prior to or at the PDR (see section 2-1.5). Following the PDR, the preliminary design and ABL, will be put under formal configuration control. Current Department of Defense (DoD) practice is for contractors to maintain configuration control over the CI performance specifications, while the government exercises requirements control at the system level.

2-1.3.4 Critical Design Review (CDR) This is a formal technical review that is conducted prior to fabrication and production of the DLSS in order to ensure that the detailed design calculations, analyses, and engineering drawings satisfy the performance requirements and standards of the DLSS. This review is used to evaluate and verify that the draft PBL, or the “build to” documentation, is sufficient to start initial manufacturing. At the CDR, 85% of the manufacturing quality drawings shall be complete. All drawings submitted for CDR shall be under formal configuration control unless otherwise permitted by the PM.

The CDR includes the evaluation of all CIs before release of the design for fabrication. Additionally, test plans are reviewed to assess if test efforts are developing sufficiently to indicate the system testing program (see section 3-6.2) will be successful. The approved detail design serves as the basis for final production planning.

Certification design reviews using NAVSEA SS521-AA-MAN-010 will normally be conducted concurrent with the PDR and CDR.

2-1.4 SYSTEM SAFETY PROGRAM

System safety applies engineering and management principles, criteria, and techniques to achieve acceptable mishap risk, within the constraints of operational effectiveness, time, and cost, throughout the system design.

It draws upon professional knowledge and specialized skills in the mathematical, physical, and scientific disciplines as well as principles and methods of engineering design and analysis, to specify and evaluate the environmental, safety, and health mishap risk associated with a system.

Experience indicates that the degree of safety achieved in a system is directly dependent upon the emphasis given. A safe design is a prerequisite for safe operations, with the goal being to produce an inherently safe product that will have the minimum safety-imposed operational restrictions. The PM shall assure that the System Safety Program meets the requirements of NAVSEAINST 5100.12, System Safety Engineering Policy.

System safety interfaces with other aspects in the overall engineering design process including human engineering; reliability, maintainability and availability (RM&A); operability, survivability, and environmental, safety, and occupational health.

2-1.4.1 System Safety Program Plan The designer shall document system safety engineering approach.

This documentation shall:

a. Describe the program’s overall system safety plan and implementation including milestones, definitions of hazard severity and probability of hazards, and a detailed risk level matrix (severity and probability). Include identification of each hazard analysis and mishap risk assessment process used.

b. Include information on system safety integration into the overall system engineering process.

c. Include the following safety analyses: health hazard assessment, system hazard analysis (see section 2-1.4.2), component level hazard analysis, system level hazard analysis (see section 2-1.4.2) and failure mode, and effects analysis (FMEA) (see section 2- 1.7.2.1).

d. Define how hazards and residual mishap risk are communicated to and accepted by the appropriate risk acceptance authority and how hazards and residual mishap risk will be tracked.

e. Include a Hazard Tracking and Closeout Plan. This plan shall maintain a tracking system that includes hazards, their closure actions, and residual mishap risk throughout the design. The designer shall keep the PM advised of the hazards and residual mishap risk.

2-1.4.2 Hazard Analysis As part of the design process for a DLSS, a hazard analysis shall be developed and submitted to the PM for approval to evaluate the effects of all possible failures (see Appendix D). Both a component level hazard analysis and a system level hazard analysis shall be performed. The component level hazard analysis is typically performed assuming that only one failure occurs in any one subsystem. The system level hazard analysis shall account for the multiple effects to a system due to any number of single failures. The hazard analysis shall describe the possible effects of a hardware failure (mechanical, electrical), software failure or operator error for each component or subsystem. Those hazards that could affect the safety or recoverability of personnel shall clearly detail what features, warnings or procedures have been incorporated into the design, operation and maintenance of the system to preclude or minimize the probability of failure. It is the responsibility of the designer to ensure that the conditions, identified as significant safety hazards are eliminated or reduced to the lowest practical level.

Hazards are not always the result of equipment failure, but may be attributed to human error when responding to a routine command, while addressing a minor problem, or from the operation of a control function at the wrong time. Operating and emergency procedures (OPs/EPs) must be specific, clear and concise in order to avoid confusion. The hazard analysis shall show that the possibility of human error has been considered in the design and that safeguards have been taken to reduce the likelihood of such an occurrence.

MIL-STD-882, System Safety Program Requirements, provides an acceptable set of guidelines to conduct proper hazard analyses. The file://NAEAWNYDFS101V.nadsusea.nads.navy.mil/USER129$/phillip.colon/00C4/Bob%20Bauer/GenSpec%20Edit/References%20in%20Document/DoD%20Standards/MIL-STD-882E.pdf application and tailoring guidelines given in MIL-STD-882 should be carefully followed in order to make the hazard analysis no more complex than is necessary in order to prove the safety of the design.

The System Safety Society’s System Safety Analysis Handbook provides expanded guidance on implementation of a System Safety Program as described in MIL-STD-882, including step-by-step instruction for completing required analyses. The PM is responsible for assuring that the risk assessment meets the requirements of NAVSEAINST 5000.8, Naval Systems Command Risk Management Policy.

Components of a hazard analysis include hazard identification, hazard…