In 2016 the Royal Navy’s new Type 45 Destroyers bought from BAE Systems were reported as breaking down in the gulf because the “water was too hot”. Want to avoid a similar calamity? Read on…
If you have ever been asked to come up with some reliability requirements then you have probably thought about defining something along the lines of “availability” or “mean time to failure” (MTTF) for the system. You may have even produced a reliability block diagram, a fault tree analysis or a FMECA to support your reliability requirement.
However, have you actually thought about what you are referring to when you talk about reliability or availability? Flip this on its head – what does unreliability or unavailability look like? If you are specifying a reliability requirement then you need to be very careful that you are actually stating what the successful function of this system looks like, over what time period it operates and the environmental conditions associated with that operation.
If you don’t then you are significantly less likely to procure the system you actually want and significantly more likely to enter into a nasty commercial dispute as a consequence – like the dispute between the Ministry of Defence and BAE. So here are the three most important (and arguably most common) problems with reliability requirements – get these right and the rest of the process is easy.
Problem 1 – Not Defining Failure
Not defining what a failure is in a specification means that your reliability requirements are meaningless. A failure can constitute many things, do we mean total system outage, or a degradation of a specific function? What if something breaks in the system but it can still be utilised by the customer – is this a failure? Getting this definition right early on is the primary driving factor for all successful reliability modelling and requirement setting. Making the definition of failure unambiguous maximises the probability that the supplier will be able to design a system that you want. It is the basis for assurance.
Problem 2 – Not Specifying a Time Period
It is the persistence of quality that counts as much as the quality of the thing when new. Systems do not last forever, and in the context of reliability this is a most important aspect to consider. A reliability requirement without a corresponding time period which it functions over is like a race without a finish line. Specifying a time period is important as it provides assurance that the supplier will design a product that will exhibit the desired levels of reliability for that time period. Not doing so makes your reliability requirement meaningless, without a time period defined, the specification of time ensures that reliability does not degrade over time.
Problem 3 – Not Specifying Environmental and Operating Conditions
Similarly to specifying a time period, stating how much use the system will get and in what expected conditions ensures validity of the reliability requirement. This should be as detailed and specific as possible. I can only speculate that the systems engineer did not specify the expected equipment environmental conditions, or if they did so they got it wrong. If there is a degree of uncertainty around what environment the system will find it in, err on the side of caution and specify a broad range. Environmental conditions usually include temperature, humidity and vibration. The duty cycle of the system should also be stated, that is how often it will be used and how intensely it will be used.
All of this information helps a supplier minimise the amount of guesswork and minimises the risk of commercial dispute, which is the best deal for both parties.