System and safety engineers: best friends forever
The purpose of a safety engineer is to ensure that aerospace engineered systems provide acceptable levels of safety according, not only to regulations, but also to goals and requirements set by the aerospace companies building those systems. Safety engineering goes way beyond a set of documents used for certifying, it is a process that is intrinsically linked to design engineering. That is why the safety engineer must be present in the design process and work hand in hand with system engineers, as an essential member of the design team. The goal of this cooperation is to achieve valuable insight on system robustness, reliability and safety before design freeze, so that the results of preliminary safety analyses become input for current and future designs, thus creating an iterative process that leads to the best possible product.
A cycle of the safety assessment process consists in the development of three main deliverables: FHA, PSSA and SSA (Functional Hazard Analysis, Preliminary System Safety Assessment and System Safety Assessment). The diagram below shows how the safety studies are developed in parallel with the design development process stages. Both paths should be performed simultaneously, as inputs from each side are necessary to complete the tasks. Consequently, RAMS engineers and design engineers need to work together and get along to achieve a common goal: a robust system that performs, with safety & reliability levels according to goals set and compliant with the certification authorities.
Once completed, the conclusions of all the safety and reliability analyses need to be sent to the compliance authorities for approval. When expert safety engineers enter the development process at an early stage, the results of the safety documentation are rock solid, because the whole system design is thought for reliability and safety besides performance. However, if safety analyses have been developed solely as a means to certify, once the main design decisions have been taken, several misalignments may arise between safety and design system engineers.
Will you make the numbers work for us?
On the one hand, a safety analysis should reflect the reality of a system concept design, forcing the emergence of issues where the design doesn’t match the airworthiness levels required from certification authorities.
Once in a while, it is expected from safety engineering professionals to perform an analysis that simply verifies expectations: do your magic and make the numbers work! However, safety analyses are calculations with a sound methodology, not open to interpretation, as the assumptions taken must reflect with veracity the system under study. Let us make an example. If the mean mission time of a certain aircraft is thought to be around 1 hour, this is the parameter a safety engineer will use to build their Fault Tree Analysis. It is a malpractice to use 1 as a standard mission time for aircrafts that have longer mean periods of sustained flight, as this may tamper with the results, offering an exceedingly optimistic view of system failure rates. This type of inaccuracy in assumptions may lead to rejection from the certifying authorities in the short term or, if approval is nonetheless granted, to serious consequences in the long.
The annoying safety engineer strikes again
On the other hand, some of the safety conclusions that come to light after a substantial RAMS analysis touch on the validity of the initial concept and require substantial modifications of the original design.
Experience has taught us that those changes are not always well received by the system engineers, especially in cases where, as a result of the safety cycle studies, a relevant iteration must be performed, such as the introduction of further redundancies or the selection of a different part supplier. This process may lead to delays in the design freeze of the system and load the team with additional work. Modifications in a mature design are harder to implement and this may negatively impact the quality of the design itself. Late changes have a substantial impact in the timeline, quality and cost of the design process.
Still, some aerospace program managers consider independent safety studies a sort of engineering luxury – something which is neither affordable nor always required before the certification stage. Even in cases where certification is achieved, they perceive safety analyses as an additional cost, instead of a task intrinsic to design development. Is it possible they never had to handle the consequences of poor safety analyses performed at the last minute? Since those consequences may appear later in the product lifetime, other professionals need to deal with them. But engaging a proficient safety engineering team at an early stage of the design process is the easy way to handle certification goals, staying in budget and deadline, while achieving overall product quality and smooth customer services for the rest of the product life time. In safety, the early bird gets the worm!
