1. The following guidance is provided for the establishment and sustainment of In-Service System Safety Programs (ISSSPs) for legacy weapon systems that may or may not have had SSP requirements during original development, or where their original SSP documentation has not kept pace with aircraft configuration updates.
2. The principles of a SSP espoused in the main body of this Chapter are equally applicable to legacy weapon systems, although their application needs to be tailored to be commensurate to the scope of design changes and assessments undertaken at the SPO.
ISSSP TERMS OF REFERENCE
3. The overarching Terms Of Reference (TOR) for any ISSSP should be:
a. to value add,
b. to maximise use of the existing SPO Engineering Management System (EMS) and procedures, c. to optimise use of existing System Safety related data, and
d. to minimise the impact on SPO resources.
THE ISSSP ISSSP Scope
4. As a minimum, the scope of ISSSPs includes:
a. the generation of an ISSSP Plan (ISSSPP) to detail the value-added system safety methodologies to be applied to all SPO technical activities;
b. reliability monitoring of safety critical systems/items;
c. undertaking hazard analysis of weapon system design changes and assessments commensurate to risk, and accepting identified risks within a formal framework; and
d. presenting results of key System Safety activities to the annual Airworthiness Board (AwB).
ISSSPP Content
5. ISSSPP considerations should mirror applicable content of project SSPPs described in earlier Annexes of this Chapter. ISSSP methodologies should be tailored to ensure coverage of hardware, software and human factors’
considerations by all SPO sections involved in design or design assessments. An example ISSSPP is provided at appendix 1.
6. Additional considerations for ISSSPP content include:
a. outlining all ISSSP activities and their timing, and
b. the definition of the exact documents which constitute the System Safety Document Baseline (SDBL) for the aircraft system.
ISSSP Execution
7. In executing the ISSSP and establishing the optimum effort required, the following guidance is provided:
a. The implementation of the ISSSP through the existing SPO EMS processes (such as EMERALD) is likely to be least time consuming. Typically many ISSSP requirements are already being considered
AAP 7001.054 Annex F to Sect 2 Chap 1
1F–2
and/or reported by the EMS, but are not recognised as such. Where required, a slight modification of how specific data is presented will assist.
b. Typically SPOs already possess a Standing Instruction (SI) process and a SI on ‘Judgement of Significance (JOS)’. A new ISSSPP SI complementing this and describing the extent of the ISSSP, the flexible ISSSP safety assessment processes, and HRI definition and use to assist with the JOS determinations would provide enough guidance for an effective ISSSP. This process can improve the efficiency of JOS determinations by reducing undue conservatism.
c. Document an assessment’s or design change’s tailored system safety approach only when ‘significant’.
The system safety approach would then describe the safety methodology, and residual risk acceptance criteria to be applied based on the HRI, and justify the type of hazard analyses to be completed.
d. Define the analysis techniques to be applied dependent on complexity and design change significance.
e. Generate tailored Safety Case Reports as part of the design acceptance rigour only for significant ECPs and projects.
f. Document design change or assessment hazards through a separate Hazard Log form on EMERALD.
This will ensure its use during the extant EMS process and specifically document all hazards and their HRIs (pre and post-mitigation), to allow for data manipulation and tracking of individual mitigations.
A standard Hazard Log data entry format would also assist in ensuring that all necessary considerations are applied to the change or assessment. A sample data entry format could be:
Unique Hazard Identifier:
Hazard Description:
Initial HRI:
Phase that Hazard is Identified for: [Design, Integration, Operation, Maintenance, Disposal]
Potential Contributory Causes to Hazard:
HARDWARE – Post Mitigation HRI (Short Term):
Potential Mitigating Solutions (Long-term):
HARDWARE – SOFTWARE – HUMAN FACTORS – Post Mitigation HRI (Long Term):
Status of Mitigations:
HARDWARE – SOFTWARE – HUMAN FACTORS – g. Create a Safety Critical Items/Systems (SCIS) List.
(1) A list of weapon system SCIS can be created from the Technical Maintenance Plan. Any of these SCIS that exhibit significant negative Mean Time Between Failure (MTBF) trending from the originally designed/predicted MTBF need to be assessed for risk and mitigated. Typically, differences considered significant would be of an order of magnitude or more, or an approximate 50% reduction, depending on the MTBF figure. Predicted MTBFs would have been used by the aircraft manufacturers to introduce an inherent level of safety in the design.
This is the information they would have used to determine redundancies required and to justify sufficient risk mitigation for SCIS.
(2) Should originally designed/predicted MTBF data not be available, or item/system architecture changed significantly from original design, determining whether original design safety margins
AAP 7001.054 Annex F to Sect 2 Chap 1
1F–3 are being retained is more difficult. However, platform flying hours and comparisons against previous years’ in-service MTBF data will also assist in identifying negative trends and infer design safety levels, albeit with a lower level of confidence. For these cases, difference margins will need to be smaller, and the more years’ worth of data is available, the better the long-term comparisons.
(3) AAP 7001.038-2 Section 3 Chapter 2 contains the definition of safety critical items. As an additional confidence check, a true SCIS is one whereby loss of the function provided by that item/system could, in a worst credible representative environment, directly (ie without additional events occurring) affect the aircraft’s ability for continued safe flight and landing for its SOI. Most SCIS lists could therefore be expected to contain the following systems:
(a) powerplant,
h. The appointment of a SPO System Safety Manager and deputy will ensure that workload is evenly distributed and no more demanding than a significant secondary duty. Typically, these individuals are senior SPO personnel, thus allowing them to provide as-required mentor services.
i. System Safety training provided both at ISSSP commencement and cyclically thereafter is crucial to program acceptance and viability. Training is most effective when tailored with an in-service focus, including topical SPO case studies.
j. Research the availability of existing System Safety Data for the weapon system’s configuration. If this data exists it will significantly simplify the ISSSP through:
(1) an existing reference to qualitative or quantitative information on potential hazards already associated with specific systems or LRUs;
(2) already identifying a methodology for the analysis of specific systems or LRUs;
(3) the provision of existing interfaces to other systems; and
(4) the provision of a more holistic ‘system’ picture to assist with residual risk acceptance.
k. Determine the timing for a validation of the predicted MTBFs provided in the design phase of the aircraft system, as discussed in the body of this Chapter. Typically, validation of predicted MTBF can only occur when the original design is sufficiently robust and an adequate sample size exists (generally 4-7 years after introduction into service).
l. Establish close liaisons with the Force Element Group’s operational Subject Matter Experts (SMEs) and Squadron and/or Wing Aviation Safety Officers (ASOs). Typically these individuals are capable of providing valuable insights and advice about technical options under consideration. ASOs are also typically trained in aviation risk management and crew resource management, and are therefore current with topical safety issues and HRI mitigation, albeit from an operational airworthiness perspective.
This feedback can be provided through Configuration Control Boards (CCBs) and/or System Safety Working Groups, as necessary.
AAP 7001.054 Annex F to Sect 2 Chap 1
1F–4
m. Establish an effective System Safety Working Group by generating a Charter and agreeing on how best to implement ISSSP goals. Discussions typically expected at SSWGs could be alternately embedded within design reviews and CCB agendas.
n. Include ISSSP checklists into design change/assessment processes to assist in the identification and consideration of both internal and external interfaces for hardware, software and human hazard causal factors during design, integration, operation, maintenance and disposal.
Appendix
1. Example In-Service System Safety Program Plan (SSPP) for XXSPO.
AAP 7001.054 Appendix 1 to Annex F Sect 2 Chap 1
1F1–1