In both System Development and Safety Assessment processes, the use of assumptions is a frequent practice to advance in the system life cycle. For our engineering efforts to have a solid basis, we need to be able to manage assumptions with a sound methodology. In this article, we offer some tips to solidly manage assumptions during aircraft system development and the safety assessment process of complex aerospace systems.
HOW ARE ASSUMPTIONS DEFINED IN AIRCRAFT SYSTEM DEVELOPMENT?
The ARP 4754A defines assumptions as statements, principles, and/or premises offered without proof. Aircraft system development is a complex, iterative, and concurrent process influenced by numerous factors, including top-down and bottom-up considerations, as well as the misalignment of system development phases of interfering systems. Due to the inherent uncertainties in the preliminary stages of development, the necessary information may not be provable, necessitating engineers to make assumptions. By meticulously documenting and managing assumptions, System and Safety Engineers can significantly mitigate the risk of compromising the successful realization of System and Safety Requirements.
Note: To delve deeper into System Requirements Development, we encourage you to read the article ‘From complexity to clarity: how to develop requirements for aircraft systems?’
Whether you are a System or Safety Engineer, this article offers valuable insights to effectively capture and manage assumptions.
HOW ARE ASSUMPTIONS CATEGORIZED?
In ARP 4754A, assumptions are classified into the following categories:
Operational / environmental assumptions pertain to operational procedures, maintenance, air traffic, flight dynamics, etc.
Example: A conservative Ground Operating Factor (GOF) value of 1.3 has been applied in the absence of a definitively established GOF.
Design assumptions include crew interface assumptions (e.g., response times, display interpretation, physical limitations), system interface (e.g., data exchange or data signal), and reliability assumptions (e.g., failure latency, exposure time, MTBF).
Example: The Failure Rate for the Erroneous Failure of the PFD is less than 1E-07 FH-1
Serviceability assumptions usually assume that provisions for service and repair do not degrade safety.
Installation assumptions describe the installation conditions, e.g. separation, isolation, cable binding, wire sizing, environment, power hook-up, circuit breaker sizing, ventilation, drainage, sources of contamination, mount integrity, grounding, and shielding
Example: Standby Instrument is powered by 2 independent power buses.
WHAT ARE ASSUMPTION VALIDATION METHODS?
ARP 4754A states that all assumptions shall be validated through the same rigor validation process as system requirements wherein an independent reviewer should challenge the assumptions.
The following methods can be used to validate assumptions:
- Review. Includes examination of the item against applicable documentation like industry standards and practice, service and maintenance procedures, drawings etc. or engineering judgment.
- Analysis (including modelling and simulation) involves using analytical data, like Human Factor Analysis or simulation to show theoretical compliance. Analysis may also be based on ‘similarity’ by reviewing similar items and confirming that characteristics can be legitimately used in current system.
- Test is a quantitative procedure to prove performance using stated objective criteria.
ASSUMPTIONS IN SYSTEM DEVELOPMENT
During the initial phases of development, when drafting requirements, it is not uncommon to encounter gaps in available data. This is where assumptions play a crucial role. ARP4754A (Section 5.4.2, d) stipulates that all assumptions, like requirements, must undergo a validation process. Therefore, the management of assumptions is an integral component that should be outlined in the System Validation Plan, and validating an assumption transforms it into an objective within the Requirements Validation Process (ARP4754A, Table A-1, objective No. 4.2).
ASSUMPTIONS IN SAFETY ASSESMENT
The initial safety assessment, where all categories of assumptions may be introduced, is AFHA or SFHA. These assumptions will have a cascading impact on subsequent analyses, including PASA, PSSA, CMA, FMEA/FMES.
In our proposition for assumption management, we recommend that each assumption be accompanied by the following attributes:
Unique ID is a unique alphanumeric or numeric label assigned to an assumption within the safety assessment process to maintain the assumption.
Recommendation: The following notation may be used:
FUEL_SFHA_A_01 – assumption 01, introduced in ATA 28 (Fuel) SFHA
AVX_PSSA_A_03 – assumption 03, introduced in ATA 21, 31, 34 (AVX) PSSA
Assumption is a core field of the assumption. Statements, principles, and/or premises offered without proof.
SFC ID is System Failure Condition ID, which is affected by Assumption.
Validation Method entails the selection of the appropriate validation technique for the assumption, which can include Review, Analysis, and/or Testing.”
Status (Open, Closed, In Progress) indicates the current validation status of assumptions.”
Records include all the validation evidence.
The example of assumptions table is presented below:
In any Safety Assessment, the inclusion of such a table is imperative, as it facilitates the precise management of assumptions. After delving into the essential attributes that define assumptions, the next step of assumption management is understanding the structured workflow that brings them to life.
Assumption introduction initiates with formulation, most often sourced from engineering experience, guidance materials, etc. Once formulated, it is assigned an ID and an ‘open’ status. Per ARP4754A, an independent validator should validate the assumption (‘in progress’ status). After the validation, the evidence of validation should be recorded, and the status should be changed to ‘closed’. Depending on the selected type of validation this can be a review report, peer review report, human factors analysis, flight test reports, etc.
An assumption can be removed from the Safety Assessments only when it no longer qualifies as an Assumption. This commonly occurs when Safety Engineers make design-related assumptions due to a lack of information in the SDD for analysis. The iterative development process allows System Engineers to incorporate essential information in the subsequent SDD version, leading to the removal of the assumption from the analysis.
?All assumptions should undergo a validation process at the earliest opportunity. However, it is allowed in Preliminary Safety Assessments: FHA, PASA, and PSSA (the left side of the V-cycle Model) to have unvalidated Assumptions. In Final Safety Assessment: ASA, SSA, FMEA/FMES (the right side of the V-cycle Model), every single assumption must be rigorously validated leaving no room for exceptions.
HUMAN FACTORS ASSUMPTIONS IN SAFETY ASSESSMENT
A special place in System Safety Assessments is occupied by crew interface assumption from the design category assumption, they are also commonly called Flight Crew Human Factors (HF) Assumption. So, for example, the CM-SA-002 aims to stress the importance of considering human factors in aircraft and system safety assessments for large airplanes.
Note: The CM-SA-002 affects applicants showing compliance with CS 25.1309 for certification of a new type design, significant major changes to a type design or any major change that introduces new failure conditions or significantly affects existing failure conditions (change in flight deck effects or in assumed flight crew reaction) on large aeroplanes.
The severity of some Failure Conditions in FHAs may be mitigated by flight crew recognition and response, in these cases it would directly affect the failure condition classification and safety objectives. The adequacy of such mitigation depends on the capability of flight crews to perform the actions that are expected from them. Thus, it is important to conduct activities to demonstrate the validity of HF assumptions.
Some assumptions may be considered obvious, while others may require deeper discussion or more complex analysis. The CM-SA-002 provides the following process to determine the acceptable approach for the management of HF assumptions based on the level of scrutiny.
The following table provides recommended methods, means, and deliverables depending on the confidence degree. The level of confidence drives the level of scrutiny.
As illustrated in the table, a decrease in the level of confidence necessitates a heightened level of rigor in the validation process of HF Assumptions.
?CM-SA-002 (section 3.3) states that the expected flight crew behaviour should be documented as an assumption within the safety assessment process. A process should be defined and documented taking into account the guidance provided in section 3.2 to confirm these assumptions and ensure the traceability to the supporting evidence. The applicants should also provide a statement that all relevant assumptions are confirmed prior or jointly with the submission of the final safety assessments.
THE BOTTOM LINE
Since the development process is complex, iterative, and sometimes uncertain, engineers have to rely on assumptions, which may jeopardize the meeting of System and Safety Requirements. Nevertheless, by using a rigorous, well-documented assumption management process, System and Safety Engineers can mitigate potential risks and base decisions on proven judgment to ensure the highest levels of safety in aviation.
DMD Solutions provides a comprehensive range of RAMS solutions to help organizations ensure the reliability, availability, maintainability, and safety of their product. Connect with our expert team for collaborations, we would be happy to assist you. Contact us now to receive support.