the PSP to the specific needs and SRM requirements of the program consistent with the phase  of the AMS lifecycle that the program is entering. The tailoring of the PSP must be in  accordance with agreements made at the Safety Strategy Meeting (SSM) (refer to  Section 5.2  for details). The ATO Chief Safety Engineer may require programs to identify additional features  or text for inclusion.  A PSP must be developed and tailored specifically for each program requesting an IARD. The  PSP supports the IARD and is completed and approved prior to the JRC Secretariat’s cut-off  date for the IARD. Early in the acquisition lifecycle, the PSP may be very high level as many of  the program specifics are not yet known. The PO further develops the PSP as the acquisition  process matures. The PSP must include the PO’s methodology and approach to meeting the development  assurance safety requirements.  See Appendix A for further details on preparing a PSP.  The OSA is a tool for the assessment of hazard severity. The OSA identifies and assesses the  hazards in a system, defines safety requirements, and builds a foundation for follow-on  institutional safety analyses. The OSA provides a disciplined method of objectively assessing  the safety requirements of new NAS concepts and systems, typically for Communication,  Navigation, and Surveillance (CNS) and Air Traffic Management (ATM) systems. It also  establishes how safety requirements are to be allocated between air and ground components  and how this might influence performance, interoperability, and monitoring. The OSA is  completed during the CRD phase and must be approved prior to the JRC Secretariat’s cut-off  date for the IARD, which is about two weeks before the IARD JRC meeting date. The OSA provides the system designers and management with a set of safety goals for design. It also provides an operational and environmental description, a Preliminary Hazard List (PHL)  for the proposal, and an assessment of the potential severity of the hazards listed in the PHL. The results of any earlier conducted safety analyses or assessments that impact the program  (such as a Functional Hazard Assessment (FHA)) are inputs to the OSA. In addition, certain  planning must occur prior to the IARD, such as development of an IAP to include relevant safety  information.  For replacement, removal, or reconfiguration of existing NAS systems, significant existing  design, testing, field performance, NAS operations research, and/or detailed support  documentation (perhaps including recent SRM documents or portfolio SRM documents) may  already exist; these may apply substantially to the new proposed action. Consider an audit for  applicable and reusable baseline documents and SRM documents that can form a sound basis  for legacy architecture, requirements, design, performance, and known NAS constraints. See Appendix C for further details on preparing an OSA.  Section 2.2.1.2 of the SMS Manual requires designers of NAS hardware and software to design  systems that will not impose hazardous conditions during abnormal performance. AMS,  Section 4.12, requires programs (e.g., systems, hardware components, and software  components) to conduct product development at a rigor commensurate with the severity of the  resultant hazard should that product experience failure. This may result in different  2.3.2.1.4 System Development Assurance  2.3.2.1.3 OSA 2_SRMGSA_202003  Originally published March 2020  Uncontrolled copy when downloaded  11