24R0003 Attachment IX W GEN SPEC FOR DIVING SYSTEMS.pdf

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 assessment, and hazard mitigation as discussed below.

2-1.4.2.1 Hazard Identification Hazards are identified through a systematic hazard analysis process encompassing detailed analysis of system hardware and software, the operational environment, and the intended use or application.

Historical hazard and mishap data shall be considered and utilized, including lessons learned from other systems. The identification of hazards is the responsibility of all program members. During hazard identification, consider hazards that could occur over the system life cycle.

2-1.4.2.1.1 Hazard Analysis Tools and Techniques The safety analyst may use a broad range of well documented tools with associated techniques, depending upon the complexity of the system and as found acceptable by the PM. The safety analyst may introduce different methods and new methods, not identified here, as long as found acceptable to the PM, all prior to implementation.

Many analysis techniques are available for evaluating systems safety and reliability. Usually several techniques are employed in combination to produce an integrated, methodical analysis approach, for identification of high-risk concerns. A single technique may, in some instances, be most prudent given time and schedule restraints, system complexity, and other factors.

Qualitative versus Quantitative Analysis – For DLSSs, the qualitative approach, with emphasis upon tasking an appropriate DLSS experienced safety analyst, is the prudent approach. The quantitative approach considers the complexity and uniqueness of components, systems and sub-systems associated with DLSS, to completing a robust quantitative analysis of the entire system. The following suggestive techniques have been proven effective in both unique and complex DLSS for decades, not requiring performing a quantitative analysis.

a. Preliminary Hazard Analysis (PHA) – This procedure is used to quickly review, document and initially identify all potentially hazardous conditions within a system. Within the scope of the PHA are operational, equipment, total system, and system interface hazards. The purpose of a PHA is to identify and evaluate hazards, then to identify issues requiring further in-depth analysis. The PHA qualitatively assesses undesirable or potentially hazardous conditions; it normally augments a more rigorous descriptive narrative analysis (DNA); it does not normally stand alone. The PHAs objectives are to identify potential hazards, evaluate their impact upon safety and reliability and specify, if necessary, methods of analysis used during further investigations, such as fault tree analyses (FTA), or DNAs.

b. DNA – DNAs are used to present a detailed risk analysis in narrative format. DNAs are free form narratives which substantiate risk assessments generally disclosed in the hazard analysis. DNAs are a forum for discussing component/system failure histories, hazard scenarios, relevant technical facts, and known mitigating factors i.e., design changes, testing, calculations, etc. Complex component interactions can be discussed with respect to system diagrams, fault tree diagrams, or failure mode tables. The DNA format is very flexible, allowing the analyst to focus on the most probable and/or severe system failures and to develop the analysis rationale for any desired level of detail. Where PHA methodology is insufficient to provide the proper level of detail needed for risk assessment, the PHA can be supplemented by an associated DNA.

The risk assessments disclosed by the DNA are a combined evaluation of hazard severity and frequency of occurrence.

c. FTA and Success Tree Analysis (STA) – A deductive procedure for identifying possible modes of failure which would cause a specified undesired event in a given system. FTAs may be quantitative or qualitative and may be used to analyze complex systems for both safety and reliability. FTA logic can be inverted to produce an STA if a different perspective is desired. For quantitative FTAs/STAs, relative values of failures are assigned to provide the relative probability of the top event's occurrence computed from the relative probability of the end event's occurrence. This also reveals the relative importance of a system's various features and functions. If values are not assigned appropriately, failure importance may be distorted or masked by other failures. As substantive data becomes available on failure rates, this information can be substituted for the relative values and an improved system safety/reliability model can be constructed.

Qualitative FTAs/STAs may be performed without statistical analysis. This method applies to systems which benefit from the mapping of fault events and does not require a formal statistical analysis. Often the resultant map (tree) can, upon inspection, reveal paths to system failure which are most likely to occur. For more information reference NRC NUREG-0492, Fault Tree Handbook.

d. Toxic/Flammability Safety Analysis – Safety studies which disclose increased risks to personnel resulting from the introduction of new, non-metallic materials into closed space DLSS/Chamber areas and oxygen (O2) enriched environments. Like all other analysis types, the Toxic/Flammability safety analysis utilizes standard analysis methods (PHAs, DNAs, STAs, etc.) and summarizes overall risk impacts based on the hazard risk assessment matrix. These safety analyses are normally supported by development of Toxic/Flammability composite databases which exhaustively catalog all non-metallic materials in the DLSS. While the databases must be maintained accurately for the life of the project, they need not be contained within a single document.

Toxic/Flammability safety analyses are PM approval documents.

2-1.4.2.2 Hazard Assessment The severity and probability of the risk associated with each identified hazard shall be assessed by determining the potential negative impact of the hazard on personnel, facilities, equipment, operations, the public, and the environment, as well as on the system itself.

2-1.4.2.3 Hazard Mitigation The hazard analysis shall identify potential risk mitigation alternatives and the expected effectiveness of each alternative or method. Risk mitigation is an iterative process that culminates when the residual risk has been reduced to an acceptable level as deemed by the PM. The system safety design order of precedence for mitigating identified hazards is:

a. Eliminate hazards through design selection. If unable to eliminate an identified hazard, reduce the associated mishap risk to an acceptable level through design selection.

b. Incorporate safety devices. If unable to reduce the associated mishap risk through design selection, reduce the mishap risk to an acceptable level using protective safety features or devices.

c. Provide warning devices. If safety devices do not adequately lower the risk of the hazard, include a detection and warning system to alert personnel to the particular hazard.

d. Develop procedures and training. Where it is impractical to eliminate hazards through design selection or to reduce the associated risk to an acceptable level with safety and warning devices, special procedures and training shall be developed.

Procedures shall identify the use of personal protective equipment (PPE). For hazards assigned catastrophic or critical mishap severity categories, avoid using warning, caution, or other written advisory as the only risk reduction method.

2-1.5 SCOPE OF CERTIFICATION (SOC) DEFINITION

Defining the SOC is part of the certification process defined in NAVSEA SS521-AA-MAN-010. SOC consists of all portions of the DLSS and its ancillary equipment that is required to ensure personnel safety. The initial SOC boundaries shall be submitted by the designer and approved by the PM at the PDR. The designer must show justification for the limits on the SOC boundaries through engineering criteria and supporting documentation. Systems and components, not initially shown to be within the SOC by the designer, shall be reviewed by the PM for their contributions to the overall safety of design. The PM is responsible for obtaining NAVSEA 00C4 SCA approval of the SOC boundaries IAW

NAVSEA SS521-AA-MAN-010.

2-1.5.1 Scope of Certification (SOC) The designer should use a hazard analysis to assist in the development of SOC boundaries. Systems, components, procedures and documentation that must be included in the SOC are those:

a. Where failure creates an immediate hazard that may result in severe injury or death.

b. Where malfunction or failure could prevent the safe return of the operators, divers, or occupants to the surface.

c. That keep operators, divers, or occupants safely on the surface following an ascent.

d. Used to rescue personnel from the DLSS and return them to the surface, support platform, or, in the case of hyperbaric chambers, to ambient conditions outside the chamber.

e. Associated with temporary test equipment affecting trim and stability conditions, both surfaced and submerged, that could threaten safe recovery of personnel.

f. Written operating procedures (OP), including pre-dive and post-dive procedures, and emergency procedures (EP),

g. Maintenance procedures for systems, subsystems, and components within the SOC including the O&M manuals and preventative maintenance packages.

h. Drawings required in the fabrication, operation, and maintenance of the system.

The PM will provide the designer with guidance on how to display the SOC boundaries in system documentation. Items included or excluded in the SOC boundary may change as the design matures and possibly even after CDR, into system fabrication. It is the responsibility of the PM to ensure SOC boundaries are finalized, approved by the NAVSEA SCA, and captured in system documentation IAW NAVSEA SS521- AA-MAN-010 prior to initial certification.

2-1.6 HUMAN SYSTEMS INTEGRATION (HSI)

The designer should consider personnel, training, environment, safety and occupational health,…