Grey items and techlogs

[silverstrata]

.

Back in the mists of time, when Pontius was a Pilot, we used to have any number of grey (intermittent) items in the ADDs, with a note saying 'please report further'. (I counted 12 ADDS for one aircraft in XXX airline.) Some of these were even pertaining to critical items, like flight instruments, controls and deicing systems. And everyone was quite happy with this arrangement.

Then we had the naughties - the age of smoke, mirrors, litigation and the telling of obvious (political) porkies to pretend that everything was fine. In this new political climate, aircraft systems were either black (failed) or white (working), and we pretended that the grey (intermittent) never happened. Never at all - amazing really. In this brave new world, the grey failure has either to be rectified (when engineering still does not know what to rectify) or signed off as fully working, even when every sentient being in aviation knows it will fail again on the next flight.

Thus the grey item has been banned from ADDs. "You cannot put that in the techlog", is the cry, "it is not an MEL item". := That may be so, but what is safer:

a. pretend it is working, when we know it is probably not?
b. put it in the ADDs, so the next crew know of the potential problem?

New management and the CAA want us to lie and cover it up. I think it is safer to tell the truth about the grey item, and let everyone know about it.




A case in point is the Turkish AMS crash.

The aircraft had a known intermittent (grey) problem with the No1 radalt, that led to the thrust levers retarding to idle. This had been previously entered in the techlog, but instead of leaving it as an open grey ADD, it was cleared as serviceable (when it clearly was not).

The net result was the next crew did not know of the potential problem and crashed. :ugh:

Had the defect been left open in the ADDs as "system intermittent fault - tested found serviceable, but please report further", the next crew would have known about it. They would have come down the ILS, seen the retarded thrust levers, recognised the symptom, recovered the power setting - and then when safely on the ground have added to the ADDS "system did it again".


Methodology a. tries to be ever so legal and proper and yet deliberately deceitful - and it succeeds in killing several people.

Methodology b. is less legal but more honest - and would have prevented an accident.


So what does our Brave New World say is the preferred methodology? Well, a. of course. You know it makes sense. ;)


.

[john_tullamarine]

I guess this is one topic for which one will find a range of opinions.

In the operation for which I work, the direction is very clear (I give it) -

If the pilot is not happy with something then he/she should write it up in the Log on the basis that that document is the pilot-to-maintainer-to-pilot's serviceability communication tool.

I don't care if the item actually is OK (ie the pilot has made a mistake in assessment - who cares - that's not the imperative) or busted, I just want the information to be fed back to the floor. [Pilots fly it, maintainers fix it and that has to be kept in mind throughout].

That way the maintainer gets the story, can investigate (including ringing the pilot to discuss what the pilot though he/she saw), and either fix it or write it off serviceable if there is nothing found and all the relevant AMM tests and checks are satisfactory.

If we have a concern that we are faced with an intermittent, deteriorating item, then we put words to indicate that we want the flightcrews to keep an eye on the previously reported problem. In general, this might be done several times for a given problem until it deteriorates sufficiently for the investigation to find something to point to where the problem actually is located. The caveat is that all the checks and test show no problem and this is sacrosanct .. ie, we don't permit the report to be written off with any hard indications of a problem ... those things are pursued until they are found and fixed.

The particular fleet is heavily electronic and, as we all accept, electronic gremlins can be more than a bit difficult to catch until they become slow enough for the maintainer to spot them before they can get back into their hiding spots. Typically something which takes a while to transit from being very intermittent through to a hard failure often can't be found easily.

Two instances come to mind for example - years ago, we had an electrical problem in the 727 sim (including some smoke etc) and it took the techs the best part of 2-3 shifts to track it down and fix it. On the present fleet, an intermittent looming short took 4 manweeks to find and then ten minutes to fix.

In this new political climate, aircraft systems were either black (failed) or white (working), and we pretended that the grey (intermittent) never happened.

Until you get into court after the accident and the barristers have all the time in the world to demonstrate that the maintenance practices were shonky .. just not worth the corporate and individual risk, I suggest.

In this brave new world, the grey failure has either to be rectified (when engineering still does not know what to rectify) or signed off as fully working, even when every sentient being in aviation knows it will fail again on the next flight.

Precisely and this is only acceptable if you have some rigid checks and balances to preclude Parker Rectification Syndrome. Whatever those checks and balances may be, the system needs some way to address progressively failing systems or components .. the maintainer sometimes just cannot find the fault despite the best of efforts and intentions. One just needs to be able to allow the condition to deteriorate to the point where it can be found.

New management and the CAA want us to lie and cover it up. I think it is safer to tell the truth about the grey item, and let everyone know about it.

Probably not for me to comment on the first item but the second seems to be the sensible way to go, subject to sufficient checks and balances to avoid sending out a known U/S other than via MEL or similar process.

Methodology b. is less legal but more honest - and would have prevented an accident.

I suggest that there is no regulatory problem if all the prescribed checks and tests came up good. The fact that we suspect there is a progressive failure at work is not the problem. Provided that all this is documented in the Tech Log then the maintenance system can rely on the pilot's reviewing the recent history prior to flight (all pilots do this, don't they ?)

[turbocharged]

An interesting point raised by SS. I read a paper by a social scientist about using 'grey data': the sorts of noise in the system that doesn't lend itself to conventional analysis.

Some time ago I was working with an engine manufacturer to develop a CBT on a new engine. The problem was that their main workforce had aged and was all coming up to retirement. So, how best to capture hundreds of years of knowledge before it walked out of the door.

The proposal was a conventional CBT based on the manufacturers documentation running alongside a 'knowledge base'. Every time someone found something not quite as the book says or new (the engine was new and additional snags were emerging as operational hours were building) these were submitted to the knowledge base. A couple of the 'real' experts would be responsible for reviewing the input. Their job was not to provide answers as such but to aggregate the data into knowledge, cross reference to the CBT and to commission changes or additions to the CBT as experience built.

Aircraft technical issues are much the same. Snags written up and then signed off 'NFF' could be grey data. You see the same with airport arrival briefings. Management of the arrival process is 'expertise' but we don't do much t capture the dynamic nature of that expertise and make sure it is shared around.

[silverstrata]

Tulermarine:
If the pilot is not happy with something then he/she should write it up in the Log on the basis that that document is the pilot-to-maintainer-to-pilot's serviceability communication tool.


That is axiomatic.

The real question is, what happens afterwards? Is the entry closed with "tested, found serviceable"? Or is it transferred to ADD with "please report further"?


The point is, is the techlog merely a pilot-to-maintainer communication tool, or is it, as you suggest, a pilot-to-maintainer-to-next-pilot communication tool?


.

[john_tullamarine]

The problem was that their main workforce had aged and was all coming up to retirement. So, how best to capture hundreds of years of knowledge before it walked out of the door.

That's probably the truest commentary I have seen for quite some time .. in many areas of activity these days. Corporate knowledge and the in/outside discipline expertise held by these experienced folks is perhaps not irreplaceable in the main .. but why lose it and then have to reinvent the wheel.

Give you a trivial f'instance .. years ago I had a performance query for which I needed an old document reference. I rang my chief performance buddy in the local regulator but, in his absence that day, the call switched through to another buddy .. this time the structures boss. After pleasantries and the like, he asked what I was ringing the other chap for .. when I explained ... his response was along the lines of .. "hang on a minute, I think I have a copy of that report in the bottom drawer". Now, why he would have that document is more than a bit strange .. the point of the tale is that, not only did he have it, he know precisely what bit of it I needed to sort out my problem and it all was totally outside his routine professional ambit ... and we put these guys out to pasture on a regular basis .. unbelieveable.

That is axiomatic.

it should be. However, in many operations (general aviation in particular) it doesn't happen.

The real question is, what happens afterwards? Is the entry closed with "tested, found serviceable"? Or is it transferred to ADD with "please report further"?

all depends on your particular system. "Checked serv IAW XYZ" is fine if you don't see a developing, but undetected problem. The sensible way to go in the latter case is to declare the concern so that all are clear on the situation. Our system is a little different procedurally but achieves the same end.

The point is, is the techlog merely a pilot-to-maintainer communication tool, or is it, as you suggest, a pilot-to-maintainer-to-next-pilot communication tool?

again, depends heavily on the system and the tech/ops airworthiness culture within which you work.. I mandate the latter in our operation for purely selfish reasons ... if it all comes unstuck, and ends up as a smoking hole in the hillside, I'm the guy who gets tied to the stake and despatched without too much ceremony.

For it to be the former, that infers pilots don't review recent history on the particular tail when taking the aircraft .. that is just inconceivably stupid to my way of thinking and at variance with every operation with which I have been familiar over the years.

[BOAC]

SS - your idea has merit for me. However, I as once told that all 'unfixed' snags eg 'ground tested and found 's' - please report further' were supposed to be transferred onto the new pages at each base turn. It never happened, and often I would sit with pages of illegible log sheet copies trying to decipher what the snag was yesterday that could not be traced. Your 'grey' system would make that so much easier. I just cannot see JT's concerns - if correct maintenance actions had been completed and no fault found, why would he be in the 'firing line'? No-one is 'carrying' an unfixed defect.

[silverstrata]

BOAC:
No-one is 'carrying' an unfixed defect..


In some respects, I beg to differ. Many a snag is not fully fixed when I fly, as the first 'test flight' is always with passengers onboard. And that is true of even the most professional of organisations.

The trouble being that some snags are difficult to trace (as every engineer knows), and the snag is unlikely to be fully fixed. Plus, the next occurrence of this snag may not occur for another few flights (a la AMS Turkish incident), and by that time there is a new crew and a new engineering shift - and nobody knows about snag XXX 4 days ago. The assumption of 'fixed' is a dangerous assumption.


My point still stands. The new 'smoke and mirrors' over-zealous regime regarding techlogs is creating risk, not reducing it. We have a small team at XXX Airlines, so we just email each other with the latest odd 'grey' snag, to keep us all in the picture, but that is not possible with larger organisations (and it goes against the whole spirit of the techlog system).



Perhaps, if the CAA REALLY don't like open ADDs with wobbly PFDs and jumpy autopilots mentioned in it, they need a new class of 'defect' page.

The new Silverstrata-inspired page would be called the ACD - the 'A' Cleared Defects page. Any cleared defects - all those annoying "T-F-S" entries - would be placed in the ACDs for 14 days, so the next crews know what has been going on last week. You might say that that is what the techlog is for, but frankly I don't have time to go through the last 50 techlog pages to decipher the faint carbonised writing and illegible comments.

A separate ACD sheet would be much easier - and if employed by Turkish Airlines (among others) a nice new airliner and its crew might still be flying.



.

[john_tullamarine]

I just cannot see JT's concerns - if correct maintenance actions had been completed and no fault found, why would he be in the 'firing line'?

Perhaps my words were ill-considered. We are quite aligned in base philosophy .. my concern related to the scenario if one had a system which permitted U/Ss to be cleared either without fixing or deferring them IAW whatever the system permitted (if that's not too many circles going around and around ..)

No-one is 'carrying' an unfixed defect.

I fear that many do. Certainly is evident in some areas of the GA arena. Then, of course, there is the MEL, CFU, and so on ...

the next occurrence of this snag may not occur for another few flights

indeed, a problem. We have many histories where a fault cannot be found, hides for a week or two, jumps out to say "hi" and so on. Usually, it eventually comes out into the open, can be found, and then fixed .. but it can take quite some time, on occasion. For the strictly electronic stuff, it is not at all unusual for a problem to manifest itself for a while .. and then just quietly go away and not bother us again ... sometimes wastes a lot of time and is very, very frustrating to the boys on the floor.

nobody knows about snag XXX 4 days ago.

that is a definite fault in the crews and systems. The log either carried on the aircraft (or, at least, available preflight) should cover a reasonable history. In our case, the logs are 50 pages with multiple flights so we might see anything up to 100 - 150 flights per book. Snag details are in a subordinate log document which, likewise, is available.

We have a small team at XXX Airlines, so we just email each other with the latest odd 'grey' snag,

in my view, a silly system and very prone to missing out the guy who has the subsequent problem and need. Why can't the crews review all the recent history ? If they can't then that is a real problem

and it goes against the whole spirit of the techlog system

I think I need some philosophical guidance on what your system is setting out to do ? as that statement doesn't make a whole lot of sense to me. The techlog needs to be a living record .. tells me what the originator thought he/she saw etc ... tells me what the maintainer did to investigate and acquit the snag .. and is available to all and sundry for review .. indeed, anyone can go back to the very first flights on the fleet and read up on the history for any given tail ... just a matter of digging out the archived techlog copy from the filing cabinet.

Perhaps, if the CAA REALLY don't like open ADDs

as I'm not familiar with your local details I can't make any direct observation. However, in my view, a sensible system will have a prescribed process to declare and permit continued operation with known defects. Typical is the civil MEL process which is quite rigorous in its detail.

Another is the military CFU process which is a bit more ad hoc (which, indeed, has its own lack of procedure hazards). We use something similar and any such defect is raised in the techlog, cleared to the deferral record where it stays until it is finally rectified ... which meets your desire precisely ... the flight crew has the defect directed to their attention ..and they then can refer back to the relevant original techlog pages to get the full story.

I don't have time to go through the last 50 techlog pages to decipher the faint carbonised writing and illegible comments.

I concur with those sentiments .. the formal deferred rectification process (by whatever name) does make the thing a lot easier for the user.

[ZFT]

John,

You mentioned simulators so maybe this is pertinent to the debate.

It is a JAA (and FAA requirement) to have a Deferred Defect log within the sim Tech Log. We also use this as the vehicle for “maintainer-to-pilot's serviceability communication tool” to highlight those intermittent and frustratingly too long to resolve problems so that the SFI/TRI can brief crews before the session on potential unservicabilities they may experience. (We have a rigid policy of NOT signing off write ups with a simple ‘Could Not Duplicate’) A win/win situation as the crew are not caught out by a non performing training tool and we gather potentially invaluable data for fault finding/resolution.

(Interestingly, whilst not a requirement, the JAA did recommend displaying the DD log in all briefing rooms to ensure that any (potential) unservicabilities that could impact the training session could be addressed during the briefing. A recommendation we have fully adopted).

The DD is a simple single sheet of paper that can be readily scanned in seconds negating any need to refer back through previous tech log entries.

[john_tullamarine]

I haven't been playing with sims for some years now so I'm a bit out of the routine loop there.

However, the DD (or similar) system is fine in principle.

One concern I have is in respect of engineering (ie certification) rigour. For instance, my understanding is that the Australian military system's process permits an ad hoc approach to some extent .. I am told that there have been a few unfortunate stuff ups probably due to a lack of engineering rigour in the assessment for CFU (ie DD) status.

However, the basic idea is pretty fine.

[BOAC]

By "No-one is 'carrying' an unfixed defect." I mean in the context of SS's post - ie defect investigated and NOT PRESENT, not in the wider context of what pilots may or may not be doing on the day, nor in terms of JT's expressed concerns about stuff NOT being investigated - unless, of course, it is DDM-able?.

To avoid the situation - without SS's 'idea', or some other way of presenting a precis of recent maintenance - will impose impossible costs on the industry. EG I am cruising along and the P1 RA shows 'FAIL' 3 times for 4 seconds each. I write it up. No fault found. In the ideal world some appear to be suggesting, the a/c would need to be grounded while every mm of the RA and other avionics is changed - and even then it may not be fixed.

NO - crews are (hopefully) trained to cope with failures. YES it is good to know what MAY be lurking when that stray 5V ripples through some black box BUT the crew has to deal with the problem when it happens, as on the first occurrence of it.

Perhaps the answer is to push for a simple computer print of maintenance over, say, the last 7 days? An easy dataset to extract and simple to append to the tech log. Any issues with this?

[john_tullamarine]

That's the sort of philosophy we have ... with the only difference being that deferral requires a known U/S so is not applicable to a yet to fail gremlin situation.

With a grey snag, if all the routine tests show the system to be serviceable then I have no problem with the boys on the floor signing it off "checked serv etc" .. after all, that result defines serviceable. Especially with the electronic stuff, we have that situation arise fairly regularly .. much to the annoyance of the flightcrews. As an organisation we are doing it better as we go along .. mainly as a consequence of improving shopfloor corporate knowledge of the particular fleet's idiosyncratic behaviours .. same as for any fleet.

If, however, we suspect that there is a progressively failing scenario then that is when we consider putting in a note to the flightcrews to advise further. We also have a process whereby the flightcrew hierarchy is briefed on whatever the particular perceived problem might be.

In the ideal world some appear to be suggesting, the a/c would need to be grounded while every mm of the RA and other avionics is changed - and even then it may not be fixed.

That, of course, will never be the system purely for reasons of engineering and commercial logic ... we are in heated agreement on that point.

Unfortunately, system workability (aircraft and any other place) doesn't work in a strict black/white binary way.

[silverstrata]

We have many histories where a fault cannot be found, hides for a week or two, jumps out to say "hi" and so on.

And this is the very scenario where crews need to be aware of the 'grey' fault that is lying low for a while, via the open ADD system





We have a small team at XXX Airlines, so we just email each other with the latest odd 'grey' snag,

in my view, a silly system and very prone to missing out the guy who has the subsequent problem and need. Why can't the crews review all the recent history ? If they can't then that is a real problem

The recent history of faults will not always be in the book, hence the backdoor methodology.

If you have a problem with a major item - (for instance we had one airframe with stiff controls, one with a slow-to-activate deice system and another with a tendency not to follow LNAV) - the 'black or white' requirement for the techlog dictates that the fault cannot go in the techlog.

If the system lies outside the MEL (as most major items are) you will end up with a grounded airframe. But the system has not necessarily failed, it just has a small glitch, and the MEL cannot deal with such instances (how much extra control force is 'failed' as opposed to 'operative'?).

And if the fault CAN go into the techlog, you will just get a T.F.S. and a needless delay to the next flight. Hence the verbal complaints to engineering and the emails to crews saying 'yeah, controls still stiff but only with flap xx'.







I think I need some philosophical guidance on what your system is setting out to do ? as that statement doesn't make a whole lot of sense to me. The techlog needs to be a living record .. tells me what the originator thought he/she saw etc ... tells me what the maintainer did to investigate and acquit the snag .. and is available to all and sundry for review .. indeed, anyone can go back to the very first flights on the fleet and read up on the history for any given tail ... just a matter of digging out the archived techlog copy from the filing cabinet.

See above. Small glitches with major systems cannot go in the techlog, because the MEL cannot deal with them. The MEL is a black or white document - it details failed systems and working systems. There is no allowance in the MEL for a system that works fine, but has a small glitch once in every 5 flights.

I want to have an open ADD saying "controls stiffer than normal with flap xx deployed - please report further". But you try getting that past maintenance control. They would blow a fuse - "you cannot put that in the techlog". But it happens to be the truth.


.

[BOAC]

(1)we consider putting in a note to the flightcrews to advise further. (2)We also have a process whereby the flightcrew hierarchy is briefed on whatever the particular perceived problem might be. - (1)sounds like a good system - how do you do it, and (2)how do you ensure that the 'hierarchy' actually pass it on?

[john_tullamarine]

The guiding rule we have is "if it's worth talking about .. then put it in the book so that we can all share it".

The regulator, in our case, has a bunch of rules but, overall, their main concern is that things are open, sensible, and reasonable while being consistent with the rules.

The recent history of faults will not always be in the book

that's your first, MAJOR, problem

hence the backdoor methodology.

understood .. but it ought NOT to be necessary to go to such lengths to achieve a simple goal

If you have a problem with a major item ... the 'black or white' requirement for the techlog dictates that the fault cannot go in the techlog.

if your rules require such an approach then your rules are a tad silly. The reality is that things range from black through grey to white and whatever system you have has to recognise and handle that in some rational way if it is to be credible.

If the system lies outside the MEL (as most major items are) you will end up with a grounded airframe.

I think that you are being a little too literal with respect to the intent of the MEL. Used appropriately, the system should work more flexibly than you are suggesting. Then again, I write our MEL so I make it reasonably flexible.

the MEL cannot deal with such instances

you are trying to twist the MEL to your perception. Just call the particular system U/S and then the MEL can deal with it just fine. If that means that the bird ends up sitting on the ground .. then maybe you didn't really want to fly with that glitch ?

you will just get a T.F.S. and a needless delay to the next flight
.....
They would blow a fuse - "you cannot put that in the techlog".

that sounds to me like the flight standards, maintenance, and tech service engineering folk need to sit down over a coffee or 20 and refine the system to remove its dysfunctionality

sounds like a good system - how do you do it

simple .. in the acquitting of the snag in the techlog, the maintainer puts words at the end to suit the occasion .. such as "Further pilot reports requested". Very much a case of tailoring the words to suit the occasion. Keep in mind that we use the system as both an airworthiness system record and a day to day functional communications tool between the drivers and the maintainers and that communications tool goes both ways.

how do you ensure that the 'hierarchy' actually pass it on?

I have no functional management control over the flightcrews. However, in the present system, the flying organisation is hierarchical and I am quite comfortable that, barring the odd foul up (and we are all prone to those), the message WILL get across to the line pilots. The system is pretty open and communicative and the flight standards management folks are well motivated in my view.

[BOAC]

Trust you slept like a lamb, John :)

""Further pilot reports requested" - now you are back to my post #6 - are you sure this comment passes onto every sheet? In BA it 'died' after the first outbound.

What is wrong with a separate data dump in the tech log?

[john_tullamarine]

Trust you slept like a lamb

away home base at the moment with two of the pups ... sleep very well with a warmer body on either side on the bed .. even if rolling over is a bit of a chore.

are you sure this comment passes onto every sheet?

in our case it's not carried forward and that's fine .. I am quite happy that the flightcrews review sufficiently far back to capture anything which hasn't gone away of its own volition

On the other hand, if that caveat didn't apply for a particular operation, then one would be looking to develop an alternative system to achieve the reasonable communication aim

What is wrong with a separate data dump in the tech log?

absolutely nothing at all .. for the sake of a trivial bit of maintenance control workload. While WE don't routinely use it, we have provision to do this sort of thing if we saw a need and I would certainly make sure it happened in such a case. Two sets of circumstances .. in the event of a known U/S for which the decision has been taken to defer maintenance, we use a separate document to record such ... for a grey item we would include a writeup in the ship's folder which, again, is subject to crew review at the start of a sequence. Just the way we do things .. works for our environment ... for someone else .. I would not expect exactly the same system.

Main thing is that the system is a case of horse for courses .. you design, set up, test, and use a system that works for the particular operation it serves. Therefore, my operation's procedures need not necessarily be similar in detail to the one used on the other side of the tarmac .. although both should show a sensible set of similar functions.

[BOAC]

review sufficiently far back - there, in my flying career, has been the problem. The overwhelming need to remove the top copies at base so that the eng computer can be updated, leaving sometimes undecipherable (limp wristed writers:)) copy pages and bingo - you sometimes don't have a clue. I was under the impression that somewhere in the regs (UK) was a 'never followed' requirement to ACTUALLY transfer PRF's to the active page?

[john_tullamarine]

Our approach to problems is to find a solution which works reasonably .. including talking sternly to chaps who think that writing gently on three sheet carbons with a felt tip pen is a good trick. Guess that there's no really simple answer other than keep plugging away at developing a system which does the job.

[BOAC]

including talking sternly to chaps who think that writing gently on three sheet carbons with a felt tip pen is a good trick.

what's your hourly charging rate?:)

[john_tullamarine]

what's your hourly charging rate?http://images.ibsrv.net/ibsrv/res/src:www.pprune.org/get/images/smilies/smile.gif

.. now, if I can just get them to take a bit more notice of me .... actually, the boys and girls aren't too bad and usually we get a fair hearing when we want them to do things a bit differently to what they might prefer.

Mind you, sometimes I wonder why I'm not just out sailing instead of bashing my head against a brick wall ...

[Sorry, mate, I inadvertently went into your post and overwrote it with mine .. bit late at night for me at the moment ... hopefully I've put it more or less back the way it was .. humblest and grovelling apologies for the incompetence ..]

[silverstrata]

JT
What is wrong with a separate data dump of the tech log?


Oh, if things were that simple....

We actually get a daily list of all ADDs before the flight. A great idea, but I can read those in the techlog. I did suggest it would be more useful to have the last 60 days CLOSED items, but it would seem that this suggestion is more than my life is worth. :ugh:

I have never ceased to be amazed at how slow aviation is to take up ideas, how many times it tries to reinvent the same wheel, and how it desperately tries to eliminate all tall poppies. It is the most depressing of industries (having come from another industry entirely).

I will start another thread about another gripe.

[BOAC]

JT - I would never have noticed.:)

SS - it was not ADDs or closed stuff particularly (although the latter is always good for those long cruise legs), just a print of the 'PRFs'.