The reporters state that the software has been successfully in use for some time in [other aircraft type] and when introduced to the [aircraft type], the previous paper performance charts were removed from the fleet. The reporters state that since the software went live on [date], data limitations and anomalies are resulting in inaccurate performance calculations. Specifically in relation to:
- calculating landing distances in abnormal landing configurations, that is, the software will only calculate to the maximum structural landing weight and cannot compensate for overweight landings. Given the fleet nearly always depart above their maximum landing weight, if an incident occurs that requires an immediate return, the reporters are concerned how they are able to determine whether a landing is permitted, particularly when using a short runway.
- performance calculations for wet runways are inaccurate. At [location] specifically, this is an issue, as the software does not appear to be able to calculate a temperature above 26C.
- a lack of consideration for a tailwind component for take-off performance. At [location 2], crew typically accept a tailwind and depart from runway [number]. This has resulted in the regulated take-off weight being lower than previously permitted.
The reporters advise that the solution or ‘work around’ for these issues is to contact headquarters so they can refer to the previously used paper charts to provide the accurate calculations. The reporters query why the charts cannot remain in the aircraft until these glitches/limitations in the software are resolved.
While the reporters are supportive of the company highlighting the limitations of the software, and also providing assurances to address the glitches/limitations, the reporters query what testing and quality assurance process was undertaken on the software prior to it going live.
Operator's response (Operator 1)
Regarding the specific questions raised within the report (i.e. testing and quality assurance prior to rolling out software), I can confirm that extensive testing was completed prior to rolling out the software. This in fact resulted in a revised “go live” date of several weeks, while the team satisfied themselves of the integrity of the system. As with all systems and changes there are always opportunities to improve and while we felt that our consultation was thorough, this report highlights some deficiencies.
Further to the above comments regarding testing and quality assurance, we would like to also advise that this report has been entered into our safety system and will be treated as if it had been submitted in the standard manner. This will include a safety assessment with associated feedback to the entire workforce. This assessment will be conducted by our independent safety team. Finally, we have committed to emailing the pilot workforce to ensure that the immediate concerns are addressed.
Regulator's response (Regulator 1)
- The “go live” date was delayed several weeks due to extensive testing.
- A safety assessment is being conducted by an independent safety team (the report is not finalised).
- The operator confirmed there was some initial issues and addressed these in an email to all pilots on [dates].
- Take off information provided to the crew by [software] was more conservative and the landing information was indicating a small decrease in length required for wet runways (for an 800 metre wet runway 13 metres difference to the previous software used).
- There is information provided by the previous software that is not available with [new software] – this information related to multiple system failures and overweight landings. It is not a requirement to provide this information.
- A Notice to All Aircrew was issued on [date] formally addressing the issues and differences to the previous software.
- [Software company] is based in the United States and provides aircraft performance information for over 350 types of aircraft. They provide a 24/7 hotline for any last minute NOTAMS, or aircraft configuration changes. A number of Australian operators use [software].
CASA considers the REPCON not to be a safety concern. CASA is satisfied that the operator has taken the appropriate action through their Safety Management System to address any issues with the software provided.