Airbus Cb Reset

[Pei Tebow]

WhenI fly two legs i.e. simulate a turn-around, I just noticed that sometimes the FMS is "reset", sometimes not. Not means: all data from just completed flight is still there and I need to overwrite it, which can be error-prone.

I don't know what the trigger for automatic reset is (thought it was below a certain speed and after being on the ground for so many seconds) but if it doesn't do it then enter the new departure/destination into the box on the INIT A page and should reset it for you. Failing this switch the nav databases back and forth

I found out that if you are importing a flight plan file from, lets say, simbrief (fms file type), and than you load it into the MCDU from there (LOAD option on Init A page), than upon landing the MCDU is not able to erase the flight plan that is currently on the FMS folder of Xplane.

For the first case and to prepare the next leg (you have imported an fms file from simbrief to fly the first leg), go to INIT A page, fill in the FROM/TO manually, than load the new fms file for the new flight again. Than check out at FPLAN page that indeed you have the From Airport on the top of the page, and are able to load runway and SID.

If for instance, on the top of the FPLAN page only a waypoint is shown, than note that this is the first waypoint that is on your simbrief flight plan (which corresponds to the last point of the SID and the first point of the route as described in simbrief flight plan) and this is what it loads from the new fms file. Repeat the FROM/TO sequence again, and than load again the fms file. Check on FPLAN page that now you have the From airport on top of the page and are able to select runways and SIDS normally.

All information was entered manually for the first leg. But I recall having had issues with thrust reversers after touch down, so it might be that I advanced the thrust levers briefly forward, before I realized reversers were not deployed. That would explain why there was no reset, as - despite being on the runway - TOGA mode became active. For the second leg I changed From/To on INIT, but that didn't reset. I didn't try switching the Nav DB.

I just retried a turnaround with the A321 (everything entered manually, no FP loaded), despite being on the ground for more than 30s and not having had a go around, the FMC will not enter the "done" phase. Cycling the database does the trick, at least to some extent. Anything I might have missed?

OK guys, I figured when this happens: The FMGS may not reset, if the time between touchdown and Ground speed All right! I'll be on the lookout for an accidental lack of reset just in case, but glad the fix is included, as I encountered it on a regular basis (like 1 out of 10 flights) and it was kind of driving me nuts (I spent quite a lot of time trying to find a common denominator -- without success, and thus unable to provide a usable bug report for you) ?

I just tried this with the A319 v1.6 (complete fresh install) and the FMGS did not reset: touch-down on RWY, medium auto-brake, activated reversers, advance levers and retract when reaching 80 kts, deactive reversers, retract spoilers and flaps, hit toe-brakes briefly to disengage auto-brakes as tower asked to vacated quickly, probably > 30kts down the runway until reaching first taxiway. Complete stop after having left the runway, landings lights and strobes off, APU on, continue taxi to gate. There shutdown. When I now check the MCDU I still see all the data of the just completed flight.

I'd rather just find what is causing this, fix it and never touch flight phase switching again. You won't be able to put enough data into the log to debug this, for that I need to execute the situation with my debugger attached.

It looks you did not properly sequence your flight plan after flying a portion in heading mode. The TO waypoint is SA750 which is a good 20NM from your current position, the FMGS distance to destination is still 75NM, hence the FMGS does not transition into APPR phase.

The flights I made after upgrading to 1.6 were all online with ATC coverage. On all occasions, the approach controller took me off the STAR and gave me vectors and speed restrictions until final. As a rather "new" virtual Airbus driver, it didn't came to my mind that I might need to verify if the approach phase was activated and assumed (that's always a bad thing) capturing the loc i.e. glideslope would do the job.

In order to still benefit from the automation, when you get the ATC instructions to join the final leg, use the DIR TO function to tell the FMGS what you are doing.You could use RADIAL IN onto the CI19L for example such that the FMGS knows what you are doing. In that case it will switch to APPR phase automatically.

A system reset is not always the quick fix that it may seem. Performing an inappropriatemanual system reset in flight can seriously impair the safety of the flight. Multiple systemresets on the ground without performing the necessary troubleshooting actions can alsohave serious consequences. This article, developed by Airbus, addresses when systemresets are applicable and how to perform them correctly. Read the full article on Airbus Safety First here.

A system reset is the action of switching off a system and then switching it back on again with the objective to retrieve normal system behavior or recover a previously lost function.It is different from re-engaging a tripped Circuit Breaker (C/B).

Certain avionic systems, such as the Flight Management System (FMS), have an automatic reset function. The reset action is completely managed by the system that has an automatic failure detection mode. Maintenance or flight crews perform a manual reset by using the cockpit control for the system, a circuit breaker, or a dedicated reset button (also called a reset switch). This article focuses only on these types of manual resets.

Past events have highlighted how some system resets can have irreversible consequences. One example is where a system cannot be recovered after an inappropriate system reset in flight. Another example is where a reset of flight control computers is unduly performed. Depending on the system malfunction encountered, this can cause unexpected movements of the flight control surfaces, which may lead toserious consequences if performed in flight. Avionics systems are interconnected systems, therefore, a system reset of one system can have significant consequencesfor the other systems that rely on its data. Inappropriate system resets can have unexpected side effects and hide deteriorating conditions of the system. In combinationwith a failure of another system, the safety of the flight can be impaired. Therefore, it is important that maintenance personnel and flight crews only perform system resets inaccordance with the guidance in the relevant procedures, as for the cases described in this article.

There are only some very specific situations where flight crew or maintenance personnel can perform system resets, for full information refer to the original Airbus Safety First article or the full article on the EASA Air Ops Community Site.

Unauthorized resets of an aircraft system can hide a deteriorating condition of the system. What may seem to be a "quick-fix" on the ground to dispatch the aircraft can leadto a system fault reappearing in flight that may even affect the safety of the flight.

If not specifically requested in an ECAM/OEB/FCOM/QRH procedure, the flight crew can only consider attempting a reset to recover the operation of an affected system if it is listed in the System Reset table of the FCOM/QRH. If there is no reset procedure available in the System Reset table of the FCOM/QRH, which is associated with the malfunction or ECAM alert encountered, then the flight crew must NOT attempt to reset the system. Any system reset performed by the flight crew needs to be reported to maintenance personnel and must be recorded in the aircraft technical logbook, including the number of attempts and outcomes. For A320 aircraft only, in some circumstances, due to possible electrical transients, the flight crew cannot perform on-ground resets that are not listed in the reset table.

Maintenance system resets are only performed in accordance with specific TSM/AFI tasks. Troubleshooting can start with resets but should not end there. The appropriatetroubleshooting actions or at least recording actions should always follow.

For A320 aircraft only, the same on-ground resets from the System Reset table of the QRH are available in the A320 TSM and can be used to manage intermittent faults and ease the aircraft dispatch. In this case, it is possible to perform system resets that are not specifically listed in the TSM.

Manual system resets performed by flight crew or maintenance personnel are not a way to fix repetitive faults. Multiple and unreported resets can hide degraded system conditions. The fault could reappear later and have significant consequences during a flight. An efficient system for reporting and managing system resets is crucial for monitoring the health of all aircraft systems, which is key to maintaining safe aircraft operations.

3a8082e126