Why do birds have feathers?

Why do birds have feathers and why is it relevant to reliability-centered maintenance (RCM) analysis?

 I'll start with a caveat, the majority of RCM analyses that I have conducted have been 'desktop' whereby the customer expects an analysis to be delivered to them almost complete, as opposed to the far more effective 'facilitated' model whereby the customer - and other stakeholders - are intimately involved in the analysis process.

Why do things exist? That's the question and it is the impact of guessing, or not knowing, that I'm interested in.

The idea for this article came from listening to BBC's 'The Infinite Monkey Cage' podcast and the quotes contained are taken from the episode 'Dinosaurs'. Specifically, from guest panellist Dr Steve Brusatte of the University of Edinburgh and that's where we'll begin...

You look at something like a bird which has feathers. Nothing else has feathers. We don't have feathers. Frogs don't have feathers.

Birds have feathers. What do birds do? Birds fly. How do they fly? They have wings made out of feathers.

So, therefore, wings must have evolved for flight.

Coming back into the RCM arena, the image below depicts a simple hydraulic system that I use when delivering RCM training. It is flawed, it’s supposed to be. But drawing your attention to the non-return valve, circled and pointed to in red…

• You look at something like a hydraulic system that has a non-return valve.
• In a hydraulic system a non-return valve prevents hydraulic fluid flowing backwards.
• Where is it in the system? It's downstream of the pump.
• So, therefore, the non-return valve must be there to prevent reverse flow through the pump.

In both cases, the feathers and the non-return valve, it is easy to take a little understanding, blend it with a little observation and come out with a conclusion that seems reasonable and, in both examples, that’s what we’ve done. Simple, right?

But no.

Fossils of the ancestors of birds tell us that's not the case. The fossils tell us that a huge variety of dinosaurs, all across the family tree, had feathers. Simple feathers.

These little feathers that look like hair, that's how feathers started out. That's what most dinosaurs had and you can't fly with hair. The feathers of modern birds evolved from those simple feathers.

So the first simple feathers probably evolved for similar reasons to mammal hair, to keep these dinosaurs warm.

Ah. It’s not quite as simple as first thought. A little extra information, a wider perspective can change the picture. Look again at the simple hydraulic system presented earlier. If you remember we stated that the non-return valve must be there to protect the pump from reverse flow. Again, it’s pretty simple, yes?

• But, maybe not.
• Further downstream in the system is the pressure-maintaining valve (circled and pointed to in black). Its job is to prioritise the two safety-critical red actuators, in the event of system pressure dropping below a certain level, probably to give the operator reaction time in the event of system failure.
• Knowing about the pressure-maintaining valve muddies the water a little. Is the function of the non-return valve protect the pump, does it contribute to keeping pressure in the two vital red actuators along with the pressure-maintaining valve, is it both or is it something even less obvious?
• I'm not going to answer the question. This a limitation in the information that was built into this exercise but similar situations do exist in the real-world. In RCM you won't always know, you always have to try to find out but sometimes you have to settle for a well-reasoned best guess. RCM is not a discipline that enjoys certainty.

It is clear that getting this wrong can lead to incorrect, inaccurate or inefficient analysis which, in turn, will lead to undermined confidence, huge cost or worse - a possible safety implication. It is critical not just to understand what something does but, to understand why it does it - if you don’t understand that, you can’t properly identify and judge the effects of a failure to do it and that will prevent the analysis from leading to good decisions.

Up to now, the point has been theoretical. Lets take a look at how this manifests in a real analysis. I once performed RCM analysis on a flight control system. One of the key components was a package assembly (I’ll call it ‘the package’ from this point on) which contained a series of valves that were key to the operation of the system.

There were 3 inlets/outlets to the package and each one had a non-return valve. I went through the process...

• They are non-return valves and they prevent hydraulic fluid flowing backwards. They are each in different channels, therefore, they each must protect the system from the effects of three distinct circumstances.

As the analyst, I had associated the presence of the non-return valves with the protection of certain aspects of the system; the wording of the functions was good, convincing enough to pass through the activity. At the customer's request, the simpler components of a system were assigned failure modes at a slightly higher level, in this case it will have read something like 'NRV fails (Not closed)'. So, the situation was this, there was a perceived protective function and there was a bland failure mode that didn't display any obvious characteristics (which ruled out the use of condition monitoring techniques or restoration activity) but, as a dormant (the operator wouldn't normally know if the valve had failed to close) - or hidden - failure, it could be tested.

• Except, no…
• As it turned out, the non-return function of these valves, in this system, were considered superfluous but, that wasn’t identified until the end of the analytical process.

I hadn't made an error. Given the information that I had at the time, I had assigned a level of importance to the non-return valves in the system, that was based on their traditional protective role. I had misinterpreted how important they were and considering that the test did not exist and when you take into account the time spent analysing the failure modes (for both the analyst and the system expert) and then the potential to incur the cost of developing the test (and maybe the test equipment) and then the possible impact of imposing those tests across multiple, international fleets of the equipment and so on... wow, the impact of that misinterpretation starts to feel, profound.

Right at the start of this article I gave a caveat but I didn’t make it clear why. There is an argument, you see, that a facilitated approach could have avoided this scenario because a group of people - with different experiences and mindsets - would work together to agree the functions. The fact that the customer preferred this ‘desktop’ model of analysis meant that their involvement in the analysis process was cheaper but, effectively, they carried greater risk because of the opportunity for misinterpretation.

There is, and likely always will be, uncertainty in RCM. Uncertainty breeds pessimism - it must - in order for an analysis to err on the side of safety but pessimism leads to conservative analysis and that comes at a cost. The cost will likely be felt in prolonged analysis times, wasted analysis effort and/or more (or more frequent) maintenance than may really be needed.

One of the key skills of the practitioner must be to spot the warning signs of errors or misunderstandings early. That is difficult because analysis is little more than the logical application of common sense and when you write in those terms, most things will seem reasonable. Often the only indication that you get will be a slightly forced phrase or perhaps a slight misalignment with neighbouring analysis.

Always remember that context is king and words matter; forget either of those two things and it can be a minefield, this RCM thing.