NAVAIR Integrated Safety Team

HOTLINE:  (301) 342-SAFE or DSN: 342-SAFE (7233)

U.S. Navy Sailors and Marines can contact the NAVAIR Help Desk with non-emergency questions at: (301) 342-3104 or DSN: 342-3104

Toll Free "One Touch" Technical Support for the Fleet: 1-877-4-1-TOUCH or 1-877-418-6824 (then press option 2 for aviation support)

What Is The Naval Air Systems Command (NAVAIR)?

We exist to provide cost-wise readiness and dominant maritime combat power to make a great Navy/Marine Corps team better. From aircraft and weapons development to carrier launch and recovery; from sensors to real-time communications to precision targeting; from aircraft and weapons sustainment to state-of-the-art training; NAVAIR provides dominant combat effects and capabilities to the American warfighter.

NAVAIR is an Echelon 2 Command (reporting directly to CNO) who's dual mission encompasses:

  1. Responsibility for the development, production, and technical support of aircraft and airborne weapon systems for the Navy and Marine Corps.
  2. Type Commander (TYCOM) responsibility for NAVAIR aircraft.

 In that regard, the goals of the NAVAIR Safety Program are to:

  1. Increase readiness throughout the Navy by reducing aircraft systems damage and personnel injuries caused by product deficiencies.
  2. Ensure the safe operation of NAVAIR aircraft and production activities, and protect the safety of NAVAIR personnel through proactive safety awareness and operational risk management.

 What can we do for you?   NAVAIR safety efforts are divided into the following offices:

RAD: NRC Form 3 Notice to Employees (231 kb)

RAD: NRMP 19-00019-T4NP/1XNP Isolite Termination and Storage (245 kb)

RAD: NRMP 19-00019-W2NP RDTE Permit (1 mb)

RAD: CNAF NRMP 04-57025-T2NP IBIS (3 mb)

RAD: AN/AAQ-25 S-3B (formerly F-14) LANTIRN (19-00019-T3NP) (181 kb)

RAD: NAVAIR RASP Form 5104 1, Audit Checklist.pdf (58 kb)

RAD: NAVAIR 5104.2 RASP Instruction.pdf (853 kb)

RAD: NAVAIR M-5104.2 (Radiation Safety Manual) (290 kb)

RAD: IBIS Radiation Hazard Awareness and Permit Requirements Training (rev 6/2015) (858 kb)

ACFT: NAVAIR M-3750.1 Aviation Safety Manual (3 mb)

ACFT: NAVAIRINST 3750.5D Aviation Safety Management System (191 kb)

ACFT: Aeromechanics (1 mb)

ACFT: NAVAIRINST 3710.1G Contractor's Flight and Ground Ops (7 mb)

ACFT: NAVAIR 51-5-31 E28 Arresting Gear Manual (2 mb)

ACFT: Ground and Flight Risk Clause (44 kb)

SHO: NAVAIR 51-50-AAA (Shore Based Airfield Lighting and Marking) (4 mb)

SHO: NAVAIR 00-80T-114 NATOPS Air Traffic Control Facilities Manual (8 mb)

SHO: NAVFACINST 11010.44 Regional Planning Site Approval Process (79 kb)

GEN: NAVAIR Safety Policy (51 kb)

GEN: Tri-Service Safety Agreement (141 kb)

GEN: Class Desk Roster (27 kb)


Aviation Safety POCs

  • Naval Air Systems Command ASO:  COMM/DSN 301-342-SAFE (7233)
    • Weapons Systems Engineering and Test AIR 5.0:  COMM/DSN 301-342-SAFE (7233)
      • NAWC Aircraft Division Pax River:  COMM/DSN 301-342-1145
        • Naval Weapons Test Wing:  COMM/DSN 301-342-1145
          • VX-20 (Force):  COMM/DSN 301-757-3324
          • HX-21 (Rotary Wing):  COMM/DSN 301-342-1377
          • VX-23 (Strike):  COMM/DSN 301-342-5572
          • Naval Test Pilot School:  COMM/DSN 301-757-5043
        • NAS Patuxent River:  COMM/DSN 301-342-3340
      • NAWC Weapons Division Point Mugu:  DSN 437-5339 / COMM 760-939-5339
        • Naval Weapons Test Wing:  DSN 437-5339 / COMM 760-939-5339
          • VX-30 Point Mugu:  DSN 437-5791
          • VX-31 China Lake:  DSN 351-7485
        • NAWS China Lake:  DSN 437-2211 / COMM 760-437-2211
    • Industrial Fleet Readiness Centers AIR 6.0
      • North Island ASO:  COMM/DSN 619-767-1410
      • Jacksonville ASO:  COMM/DSN 904-542-5640
      • Cherry Point ASO:  DSN 451-7070
    • Supported Activities
      • Coastal Systems Command Panama City, FL:  DSN 436-5959
      • NRL Det Pax River:  COMM/DSN 301-342-3550

Occupational Safety and Health (OSH) Contacts

  • Naval Air Systems Command
    • NAVAIR Occupational Safety Manager and ARSO:  COMM/DSN 301-757-2133
    • NAVAIR Acquisition Safety / Radiation Safety: COMM/DSN 301-757-9903
    • NAWCAD
      • Naval Engineer Support Command, Lakehurst
        • OSH:  COMM/DSN 732-323-1269
        • BOS:  COMM/DSN  732-323-2525
      • NAWCAD Patuxent River
        • OSH:  COMM/DSN 301-995-3806
        • BOS:  COMM/DSN 301-342-4247
      • TSD Orlando
        • OSH and BOS:  COMM/DSN 407-380-4005
    • NAWCWD
      • NAWCWD China Lake
        • OSH:  COMM/DSN 760-939-0274
        • BOS:  760-939-2315
      • NAWCWD Point Mugu
        • OSH:  COMM/DSN 805-989-1508
    • COMFRC:  COMM/DSN 301-342-6558
      • FRC East
      • FRC Southeast
      • FRC Southwest


Back To Top

Aviation Safety

Email NAVAIR Aviation Safety at

NAVAIR is an Advisory Group member for every Navy/Marine Corps aircraft. AIR-09F is the NATOPS coordinator for NAVAIR. AIR-09F represents NAVAIR on the OPNAVINST 3710.7 and other generic manuals. AIR-4.0P, as the NATOPS Product Administrator for the entire NATOPS Program, is a required representative at every NATOPS conference and is the release authority for all NATOPS changes. Each Program Office appoints it's Class Desk to represent NAVAIR at the aircraft NATOPS conferences. All NATOPS and OPNAVINST 3710.7 change recommendations should be submitted via AIR-4.0P’s website,

NAVAIR endorses NAVAIR mishaps, but does not normally endorse Fleet mishaps. We do, however, provide Mishap Recommendation Responses (MISRECs) to Fleet mishaps, and Hazard Report Recommendation Responses (HAZRECs) to Fleet Hazards, when the TYCOM endorser address action recommendations to NAVAIR. Clearly, NAVAIR takes all recommendations seriously, and addresses each problem identified. When a Mishap/Hazard is rated as a Serious (RAC I or II) Hazard, we release a Mishap/Hazard Response (MISREC/HAZREC) message that provides our evaluation of the effectiveness of the recommendation, our plan for implementation, and when the Fleet can expect to see the fix. The MISREC/HAZREC response is provided by the PMA, and formatted and released by this office.

NAVAIR's mission is to provide the Fleet with the best combat arms possible. Aviation Safety tries to contribute to that mission by reducing the risk to our test assets, providing useful data analysis, and espousing initiatives that will improve the survivability of Naval aircraft.  PLEASE review the information contained in our links, and feel free to contact this office for additional information and ideas.

Naval Air System Command is an acquisition and engineering command charged with cradle to grave development and support for all Naval aircraft and aviation equipment.  While the Naval Safety Center investigators are well familiar with our extensive engineering support capabilities, the normal fleet aviator has not had an opportunity to become familiar with the resources at NAVAIR. This WEB site is intended to provide a short synopsis of the NAVAIR help available, and NAVAIR points of contract for any member of an aircraft mishap board (AMB).

Each program office (PMA) has a "Class Desk" who is the single point of contact for engineering issues with that aircraft. The Class Desk coordinates the engineering support available for his aircraft and should be notified anytime assistance is sought from NAVAIR. He will also be the officer responding to mishap recommendations.


Aeromechanics Safety Support Team

EIs are designed to identify causes and trends in material failures in Naval aviation. The NAVAIR EI team uses a risk assessment tool (called an EI Decision Tool) that identifies "Value Added/Non-Value Added" EIs on the basis of the Engineering Investigation request. That tool poses a series of seven questions to create a decision model. Answers to those questions determine whether the EI is safety related or a routine investigation. It also helps to rule out repetitive EIs.

To assist in the proper and efficient submission and processing of these reports, a Clearinghouse has been established and staffed by personnel located throughout NAVAIR. Contact the Clearinghouse (1-888-832-5972) if you require assistance.

EI Submissions
(Note: You must apply for a username and password. Apply under the top cab called "Site Access".)

Contractor support, usually in the form of contractor maintenance, is becoming ever more prevalent in Naval aviation. Contractor flight and ground operations are governed by NAVAIRINST 3710.1 (DCMAI 8210.1) which should be on all aviation contracts.

A mishap investigation involving contractor operations is more complicated than a normal squadron investigation. Unless the AMB includes a Government Flight Representative (GFR) as a member of the board, the AMB will need help interpreting the contractor's obligations under the contract.

The NAVAIR Aviation Safety Office (AIR-09F1) writes the NAVAIRINST 3710.1 for the Navy/Marine Corps and is an excellent point of contact for contractor issues. Further information is below under "Contractor Flight Operations"

Back To Top

Contractor Flight Operations

The Navy and the Marine Corps are increasingly using contractors to supplement, or replace, traditional Naval maintenance efforts. Although contracts providing support to fleet squadrons are usually administered by the supported command, NAVAIR is the contracting authority and provides programmatic oversight for most of the Navy/Marine Corps aviation contracts. Contracts directly supporting NAVAIR flying activities are normally administered by NAVAIR. The Defense Contract Management Agency (DCMA) normally administers the contract at any site that is not physically located on a military base.

Flight Procedures
Contractors are not required to operate in accordance with the same procedures and instructions that govern the Fleet. Federal law and Acquisition Reform policies allow the contractor to use their own company procedures, limited by contractual requirements. Those procedures must meet government approval. The performance of the contractor is monitored by a small Team of government personnel assigned to ensure compliance with the contract.

DFARS 252.228-7001, Ground and Flight Risk The Ground and Flight Risk Clause (GFRC) is included on the majority of aviation contracts by law. This clause provides for the government to pay for damages to government aircraft while the contractor is working on them - the government basically insures the contractor, an expense the government would have to pay. Clearly, as the insurer, it is incumbent on the government to minimize the risk of damage. The new Ground and Flight Risk Clause (GFRC) effective June 2010 replaces the old GFRC (DFARS 252.228-7001) and AFRC (DFARS 252-228-7002).
Contractor Flight Operations
The contractor flight procedures for Navy contracts must be in accordance with NAVAIRINST 3710.1G. CNO has assigned NAVAIR the responsibility of representing the Navy/USMC on aviation contractor issues. AIR-09F represents the Navy in writing this Instruction, and in issuing waivers to the Contractor Flight and Ground Operations instruction.

Contract Administration
Although written by DCMA for their contract administration teams, the DCMAI 8210.2 instruction gives great insight into the requirements and procedures involved in contract administration.

Members of the Contract Team

  • Procuring Contracting Officer (PCO): AIR-2.0 representative who works as part of the Program Management team to issue a contract. The PCO "owns" that contract.
  • Administrative Contracting Officer (ACO): Contracting officer who administers the contract - insuring compliance and contract fulfillment. The ACO is often "on site."
  • Aviation Program Team (APT):  The APT's purpose is to ensure all aspects of aircraft safety (flight, ground, & industrial) are adequately addressed. An APT is required by DCMA, and is strongly recommended for Navy/USMC contracts. In DCMA, the GFR, the Aviation Maintenance Manager (or Ground GFR), and the Contract Safety Specialist make up the Aviation Program Team (APT). The GFR heads the APT. In performing their duties, the APT should maintain a close liaison with the ACO and the contractor organization functional offices, particularly the QA, Property, and safety activities. The APT makes critical decisions about the safety and effectiveness of each contractor flight or ground operation. This assures that aircraft are maintained and operated by contractors in accordance with contract requirements and that the aircraft conform to the contractual requirements when delivered to the Government.
  • Government Flight Representative (GFR):  The GFR is the government's primary representative with the contractor concerning flight operations. The GFR is responsible for surveillance of those contractor aircraft flight and ground operations involving Government aircraft and other aircraft for which the Government assumes at least some of the risk of loss or damage. GFR duties and responsibilities are described in DCMA INST 8210.1, Chapter 7 (NAVAIRINST 3710.1F). Prior to assuming GFR duties the GFR appointee shall meet the following requirements:
    • A rated US military officer or Government civilian in an aviation position. The term "rated aviation officer" or "rated officer," refers to Army pilots, Air Force pilots and navigators, Navy pilots and Naval Flight Officers (NFOs).
    • Completion of the DCMA GFR Certification Course
    • Receipt of a signed GFR Delegation of Authority Letter IAW NAVAIRINST 3710.1F.

Back To Top

NAVAIR Occupational Safety and Health (OSH)

The NAVAIR Occupational Safety and Health vision is for aircraft, weapons systems, and processes that are designed with minimal potential risk of occupational injury or illnesses to operators, crew, maintainers and support personnel. The NAVAIR Occupational Safety and Health offices provide occupational safety and health services in direct support of aircraft research, development, testing and evaluation (RDT&E); acquisition; radiation safety; and intermediate/depot maintenance. Mission support personnel at NAVAIR organizations work with Base Operating Support (BOS) occupational safety and health personnel to ensure both mission specific and traditional occupational safety and health support is provided without gaps.

It is NAVAIR's goal to provide a safe, injury-free workplace. To achieve this goal NAVAIR will:

  • Integrate safety into all on- and off-duty activities, work processes, and weapon system design to enhance mission readiness, capability, and accomplishment.
  • Imbed safety culture into the total force (military, civilians, and contractors), with accountability and involvement at all levels, through the adoption of a Safety Management System.
  • Facilitate continuous improvement in safety performance by managing hazards, mitigating risk, and implementing actions to reduce mishaps, through the use of annual safety program self-assessments.
  • Maintain effective safety monitoring and performance measuring systems that support senior leadership and unit-specific metrics, data analysis for root causes and development of mitigation strategies.
  • Employ new technology and the latest management tools to facilitate individual and unit safety awareness and ownership.
  • Aggressively and transparently communicate safety successes, share hazard awareness and share near-miss lessons learned.
  • Enable safety performance by developing and maintaining a workforce of talented and skilled safety personnel, both military and civilian, that supports the seamless integration of safety into all work processes, products, and operations.
  • Using sound risk management principles, Occupational Safety and Health is integrated into all acquisitions, processes and facilities to achieve a mishap-free environment for the NAVAIR Team.



When necessary, Navy and Marine Corps aviation utilizes ionizing radiation in avionics and in non-destructive testing. For some devices used on aircraft, NAVAIR is required to maintain a Navy Radioactive Materials Permit. Under most circumstances there is very little risk to personnel or the environment. However, it is important that all users understand the permit requirements and safe handling of these devices.

 NAVAIR Naval Radioactive Permits:

All activities that may receive, possess, use or transfer the F-18 AN/AAS-38A Laser Target Designator/Ranger Pod, AN/AAQ-14 LANTIRN, C-130 In-Flight Refueling Drogue Isolites, or H-53 IBIS device must post the following:



Back To Top

System Safety

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 all phases of the system life cycle. It draws upon professional knowledge and specialized skills in the mathematical, physical, and scientific disciplines, together with the 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. The program manager and the developer must apply this emphasis during all phases of the system's life cycle. 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.

Back To Top

Software Safety

  • Software Safety FAQs
  1. Is Safety a Risk NAVAIR Assesses for PEO’s/PMA’s? YES, DODD 5000.1, Defense Acquisition, March 15, 1996; Paragraph D.1.d, establishes the requirement and need for an aggressive risk (including safety) management program for acquiring quality products. New rev of DoD 5000 Oct 2000 does not include such verbiage. Risk Assessment and Management. PMs and other acquisition managers shall continually assess program risks. Risks must be well understood, and risk management approaches developed, before decision authorities can authorize a program to proceed into the next phase of the acquisition process.
  2. What is the Authority for System/Software System Safety Risk Analysis Within NAVAIR?  Within the DOD and the acquisition corps of each branch of military service, the primary documents of interest pertaining to system safety and software development include : DOD Instruction 5000.1, Defense Acquisition; DOD 5000.2R, Mandatory Procedures for Major Defense Acquisition Programs (MDAPs) and Major Automated Information System (MAIS) Acquisition Programs; MIL-STD-498/ISO 12207, Software Development and Documentation (Whichever is Referenced in the Original Contract; and MIL-STD-882 Series, Standard Practice for System Safety.
  3. What Kind of Navy Reviews or Assessments Require Evidence of Plans/Execution of Safety Risk Mitigation?  Preliminary and Critical Design Reviews (PDR’s & CDR’s), Operational Test Readiness Reviews ( OTRR’s), In Process Reviews(IPR’s) Integrated Logistic Assessments (ILA’s) Weapons Systems Explosive Safety Review Board (WSESRB) and its Software System Technical Review Panel (SSTRP) Flight Clearances.
  4. What is the Authority for System Safety Hazard Analysis?  The MIL-STD 882 Series, the Basis of 4.1.10 System Safety Specifically Addresses: System Level Hazard Identification, Mitigation of Associated Hardware, Software, and Human Systems Interface Causal Factors and,Traceability of the Safety Critical Requirements to Implementation/Test
  5. Does a Separate Software Hazard Risk Index (HRI) Exist?  No,NAVAIR Prescribes to Only One HRI for System Level Hazards, Which Software Can Contribute To
  6. Are There Any Navy Software System Safety Guidelines?  There is the “Joint Software Systems Safety Handbook” Located at safety That Delineates “Best Practices”.
  7. What is the System/Software Safety Process?  See “System/Software Safety Process Flow” (Enclosed).
  8. When Do You Execute System/Software System Safety Analysis?  See “System/Software System Safety Milestone Chart” (Enclosed).
  9. Why is Software System Safety Considered a Subset of System Safety?  System Safety is the Overarching Discipline Which Analyzes the Whole System to Gather Evidence That the Hardware, Software, and Human Cannot Contribute to the Loss of Life, Property, and Environment.
  10. Is Systems Safety 4.1.10 or Software Engineering 4.1.11 Responsible for Software System Safety?  Systems Safety 4.1.10 , Whose Focus is Functional Hazard Analysis (PHL, PHA, SSHA, and SHA) WRT Hardware, Software, and HSI And Software Systems Safety part of Software Engineering 4.1.11, Who Analyzes and Gathers Evidence of the Software Portion of Functional Hazard Analysis, Generic Hazard Analysis WRT Software, and the Traceability Resulting Safety-Critical Requirements
  11. Does Functional Hazard Analysis Address Commercial Off-The-Shelf (COTS) and Government Off-The-Shelf (GOTS) Components?  Yes
  12. Does 4.1.10 Execute ALL of System Safety WRT Functional Hazard Analysis?  NO, Although 4.1.10 is Usually the Primary P.O.C
    1. 4.1.10 Primarily Addresses Hardware Safety. - atoms
    2. 4.1.11 Primarily Addresses Software Safety. - logic
    3. 4.6 Primarily Addresses Human Systems Interface. - cognitive and biomechanical
  13. Do You Have Any Guidelines for Developing Fault Trees as a Means for Analyzing Priority Hazards?  See “Draft Guidelines for Developing Fault Tree Hazard Analysis” (Enclosed).
  14.  Are Generic Hazards, Addressing Critical Software Engineering Practices and Software Systems Safety Features, Included in Software Systems/Software Systems Safety Analysis?  Yes,Software, Hardware and Human Systems Interface ALL Have Generic Hazards that Need to be Analyzed and the Resulting Safety Critical Requirement Mitigators Need to Be Traced to Implementation.
  15. Do You Have Any Example Generic Hazard Lists?  See “Generic Safety-Critical Requirements Guidelines” (Enclosed).You May Tailor This List, Based on the STANAG-4404 for Weapon Systems, or Develop One of Your Own.
  16. How are Systems/Software Systems Analyses, Traceability, and Residual Risk Documented as Evidence That Hazards Cannot Be Reached?  The Safety Assessment Report (SAR) or Equivalent Contains: ALL Safety Analysis Results, Including Functional and Generic Hazard Analysis. Evidence That the Resulting Safety-Critical Requirements are Traced to Implementation/ Test A Description of any Residual Risk (Risk that is not Mitigated), so Management Can Choose to Accept the Risk or Not
  17. Is there an example Software Safety Systems Program Plan appendix to the System Safety Program Plan?  Yes,See “Software System Safety Program Plan Appendix Template” (Enclosed).
  18. When Is 4.1.11 Funded to Execute/Provide Insight for Software Safety Analysis on a Program?  When There is Software Developed for a Critical Component of a System. 4.1.11 is Responsible for ALL Software Safety Analysis, Whether Actually Executing or Providing Insight. MY Support from 4.1.11 is a Joint Decision Between 4.1.10 and 4.1.11.
  19. When is Software Safety a Required Signature for a Flight Clearance?  Anytime Software is Included in the Flight Clearance Software Safety is a Required Internal Signature. Although Only the Evidence That the Delta, Since the Previous Flight, Cannot Contribute to the Loss of Airworthiness is Required, 4.1.10/4.1.11 Jointly Determines if the Software Systems Safety is N/A To Reasonably Concur That Individual System Level Hazard Software Causal Factors Have Been Mitigated, the Safety Critical Requirements are Traced to Implementation/Test, and the Hazard(s) Cannot be Reached WRT Software.
  20. What Evidence Is Looked for to Ensure that the Software/ Software Environment Cannot Contribute to the Lack of Airworthiness? See “Software System Safety Questions” (Enclosed).
  21. What is the Entrance Criteria for Block Clearance?  Acceptable Software System Safety Evidence Gathered in the Aforementioned Process for the Baseline Version(s) Delineated in the Flight Clearance.
  22. What are the Ground Rules for Establishing a Block Clearance WRT Software?  For Multiple Flights Between DT and Fleet Issue: There shall be NO new requirements (ECP’s) authorized. There shall be NO changes unless the system doesn’t meet spec (STR’s/PTR’s/etc.) If the data, algorithm, or software change impacts airworthiness, a new clearance is required. At a minimum flight control, fire subsystem control (including buoys, chaff, flares, etc.), propulsion control, critical displays, and navigation should not be impacted.

Back To Top

Software Safety Continued

23.  What Evidence is Required Between Flights WRT a Block Clearance?  A letter/form delineating: Version #(s), Change(s) description, Rationale/evidence why change does NOT impact airworthiness must be provided,(including “regression analysis” when necessary), Signature(s) of appropriate program management poc, systems safety (software and/or hardware), and testing agency.  Note: If there are changes to versions of multiple components, interoperability analysis of new changes is required and the third bullet must be complete for all versions

24.  Why is FAA Certification Not Enough?  Civilian aircraft fly in a different operational envelope than most military aircraft; many military aircraft drop weapons, fly at mach speeds, and execute special maneuvers and tasks that require all flight and mission critical components work safely. The FAA addresses some generic hazards, but does not comply with MILSTD 882 functional hazard analysis or equivalent. We appreciate any DO-178 analysis submitted as a baseline, but we need to address functional hazard analysis and the delta generics for weapon systems to be able to fly within the intended militarized envelope.

25.  What is the Software System Safety Analysis Difference Between the East and West Coast, Especially WRT Flight Clearances?The east coast not only designs software systems safety into the system, but executes an independent assessment process that gathers evidence, via analysis results, that the software/software environment cannot contribute to the loss of life, property, or environment (like NAVSEA and the WSERB SSTRP). The west coast has a software IPT lead that is authorized to certify safety without thorough system safety prescribed evidence or equivalent. Maybe it’s because software is developed organically. Mitigation by expert opinion alone should be supplemented with documented analysis evidence.

26.  Do You Have Examples of the Value Added From Executing Software Systems Safety?  Yes, although we cannot discuss specifics because of program discretion and liability, a multitude of issues have resulted including: timing (examples latency and lag of critical situational awareness) simultaneous fail negating initiation of critical 3rd fail inhibit. Erroneous threshold numbers used for timing lack of tool validation incorrect sensor detection and algorithms using the data. Out-of-range constants used for swapping in and out of algorithms planned during test. Great test plans, but lack of compliance. Incorrect software load version number annunciated to the operator, etc.


Back To Top

Laser Safety

Laser safety is governed under OPNAVINST 5100.27/MCO 5104.1.

Back To Top

Airfield Safety Waivers

Airfield Safety Waivers can be requested online using the IBONS webtool at  An account can be requested here. Please note that a CAC is required for access and foreign nationals are not authorized for access to the IBONS tool.

Back To Top

Safety Links

Back To Top