A3xx computer reset recording/documentation
Thread Starter
Join Date: Apr 2020
Location: Worldwide
Posts: 4
Likes: 0
Received 0 Likes
on
0 Posts
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 Apr 2020 at 18:49.
Join Date: Apr 2010
Location: IRS NAV ONLY
Posts: 1,230
Likes: 0
Received 0 Likes
on
0 Posts
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.
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
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.
Join Date: Jul 2005
Location: Here and there....currently here.
Posts: 217
Likes: 0
Received 7 Likes
on
3 Posts
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.
Join Date: Jun 2006
Location: B.F.E.
Posts: 228
Likes: 0
Received 0 Likes
on
0 Posts
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.
Join Date: Nov 2007
Location: VIE
Age: 37
Posts: 3
Likes: 0
Received 0 Likes
on
0 Posts
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
Join Date: Apr 2020
Location: Worldwide
Posts: 4
Likes: 0
Received 0 Likes
on
0 Posts
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.
Join Date: Mar 2001
Location: I wouldn't know.
Posts: 4,499
Likes: 0
Received 0 Likes
on
0 Posts
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.
