A3xx computer reset recording/documentation
Thread Starter
Joined: Apr 2020
Aviation Qualifications: ATPL
Posts: 5
Likes: 0
From: Worldwide
A3xx computer reset recording/documentation
Just wondering how it is done in other companies.
Recently I had an input from our management about this.
Actually, I had a fault which was listed in a QRH system reset table with note that such reset should be documented in aircraft log.
What I did - inserted fault in a tech log fault section, then inserted an actions (system reset according QRH was applied successfully) in an actions sections and signed it in a signature section (did a release). I did so as I assumed it should be a "real time" record and, if I inserted the fault, an aircraft should be somehow released for the flight.
The input was - I have no right to enter any release actions and sign them as it is for maintenance only (our Company has no procedures to dispatch aircraft by Flight Crew, so it should be only maintenance release). I seeking for further explanation, of course, (maybe I should insert such info after flight only etc.), but meanwhile it is interesting what are the procedures to document mentioned reset in other Companies.
So, if you can share how the system reset is documented in your Company, you are welcome
Thanks in advance
Recently I had an input from our management about this.
Actually, I had a fault which was listed in a QRH system reset table with note that such reset should be documented in aircraft log.
What I did - inserted fault in a tech log fault section, then inserted an actions (system reset according QRH was applied successfully) in an actions sections and signed it in a signature section (did a release). I did so as I assumed it should be a "real time" record and, if I inserted the fault, an aircraft should be somehow released for the flight.
The input was - I have no right to enter any release actions and sign them as it is for maintenance only (our Company has no procedures to dispatch aircraft by Flight Crew, so it should be only maintenance release). I seeking for further explanation, of course, (maybe I should insert such info after flight only etc.), but meanwhile it is interesting what are the procedures to document mentioned reset in other Companies.
So, if you can share how the system reset is documented in your Company, you are welcome
Thanks in advance
Last edited by Igel_1; 28th April 2020 at 18:49.
Joined: Apr 2010
Posts: 1,320
Likes: 102
From: IRS NAV ONLY
Where I work we have a very documented procedure for release to service by a qualified captain.
You write up whatever happened with the aircraft, call the company and the engineer on duty guides you through paperwork for releasing the aircraft. If the engineer is available on site, then they take responsibility for releasing the aircraft.
You write up whatever happened with the aircraft, call the company and the engineer on duty guides you through paperwork for releasing the aircraft. If the engineer is available on site, then they take responsibility for releasing the aircraft.
Joined: Jan 2004
Posts: 3,246
Likes: 202
From: Here and there
We would write it up after the flight and leave it open. An engineer will then sign it off and close the defect.
Where I used to work we operated to ports with no engineering support and had a procedure for the captain to release the aircraft to service following specific pilot maintenance actions. I've never worked anywhere where the captain can just sign off a defect log on a whim, no matter how inconsequential the defect was.
Where I used to work we operated to ports with no engineering support and had a procedure for the captain to release the aircraft to service following specific pilot maintenance actions. I've never worked anywhere where the captain can just sign off a defect log on a whim, no matter how inconsequential the defect was.
Only half a speed-brake
Joined: Apr 2003
Posts: 4,459
Likes: 136
From: Commuting not home
How to write down a succesful computer reset, on an outstation with no line maintenance on site, is a question the MCC and their quality manager need to answer.
The industry needs "cloud" TechLogs that would enable remote review and sign-off. It's long overdue and for at least the previous 5 years the ITC technology exists to make one.
To answer, in my experience procedures differ. 8/10 still have logical gaps.
The industry needs "cloud" TechLogs that would enable remote review and sign-off. It's long overdue and for at least the previous 5 years the ITC technology exists to make one.
To answer, in my experience procedures differ. 8/10 still have logical gaps.
Joined: Jul 2005
Posts: 228
Likes: 15
From: Here and there....currently here.
From an Engineering perspective - the QRH is not an authorised maintenance release document. Resets are classed as maintenance and have an AMM reference. I think in your case, a defect entry should have been made and left open, and if no Engineering support available at your transit/destination station, a call to MCC for support, or possible authorisation from company QA if you have a procedure for such instances. Even getting a local Engineering company with relevant cover and experience could be an option for a one-off approval from QA.
Joined: Jun 2006
Posts: 240
Likes: 8
From: B.F.E.
May not be in any way relevant to your particular operation but in our outfit (in the USA) there would be two possible ways to document a reset. If the reset were done as a result of a discrepancy with the aircraft (some ECAM or another), it would be written up after the flight per normal discrepancy reporting procedures to include a phrase such as “xxxx reset performed, successful” or “xxxx reset performed yyy times, unsuccessful”. The balancing entry is dealt with by maintenance personnel.
The other situation would be something like a SATCOM reset that was initiated by the crew, with the concurrence of maintenance. This would be written as an “info” write up that does not require a balancing entry to dispatch / continue.
The other situation would be something like a SATCOM reset that was initiated by the crew, with the concurrence of maintenance. This would be written as an “info” write up that does not require a balancing entry to dispatch / continue.
Joined: Nov 2007
Posts: 3
Likes: 0
From: VIE
If we do a successful computer reset according the QRH reset table, we enter it as "for info only" (eg for info only: successful AIR Pack Regulator reset performed) and therefor no maintenance release is required. If resets of one system happen more frequently maintenance will still notice it and do their part.
Thread Starter
Joined: Apr 2020
Aviation Qualifications: ATPL
Posts: 5
Likes: 0
From: Worldwide
Dear Colleagues, thanks a lot for your responces/explanation
especially to FlightDetent and Helmat, it was very useful
especially to FlightDetent and Helmat, it was very useful
Last edited by Igel_1; 1st May 2020 at 16:19.
Joined: Mar 2001
Posts: 4,563
Likes: 35
From: I wouldn't know.
In my current airline it is similar to what helmat describes, in a previous company there was no requirement to note any QRH system reset at all, so we simply did them whenever needed. We did however write reports and tech log entries if it was necessary to reset a system too many times. Mainly the ATSU which we usually had to reset several times a day as there was a persistent problem with the installed units (thales software on honeywell boxes or the other way round, simply didn't work well). But that all up to the captain of the day, if he didn't feel like it, nothing got written up.
