 |
37000 Feet | Browse and search NASA's Aviation Safety Reporting System |
|
Air carrier dispatcher reported operational issues could arise as a result of software anomalies.
| Attributes | |
| ACN | 1670924 |
| Time | |
| Date | 201908 |
| Local Time Of Day | 0001-0600 |
| Environment | |
| Light | Night |
| Aircraft 1 | |
| Make Model Name | A320 |
| Operating Under FAR Part | Part 121 |
| Flight Plan | IFR |
| Person 1 | |
| Function | Dispatcher |
| Qualification | Dispatch Dispatcher |
| Events | |
| Anomaly | No Specific Anomaly Occurred All Types |
Narrative:
There are fundamental flaws with the [flight plan manager] system being used for us method of dispatch. We have many situations where the software takes liberty changing paperwork/inputs without dispatcher being made aware of them. For example after a dispatcher creates a release by pressing the release button it is not sent to stations until after the [load report] is generated by aerodata. In the meantime the dispatcher could leave the flight to look at other things. However this releases the dispatcher lock on the flight plan and the system will take liberty in changing parameters of the flight plan. If the dispatcher were to return to the flight and not catch that there were changes made the dispatcher could submit release 1 with changes they were not aware of to the station to print. The system should not be able to make changes to the release after the dispatcher has pressed release and creating a version of the flight plan. However whether that was the case in this this instance is probably not likely. However terrain page didn't even match the points presented in the remainder of the release [flight plan] legs page. The system creating paperwork that doesn't agree with itself is not ok and indicates a lack of robust programming and verification of data. Either way the system should be hardened and known vectors for the generation of incorrect paperwork locked down.
Original NASA ASRS Text
Title: Air carrier Dispatcher reported operational issues could arise as a result of software anomalies.
Narrative: There are fundamental flaws with the [Flight Plan Manager] system being used for US method of dispatch. We have many situations where the software takes liberty changing paperwork/inputs without Dispatcher being made aware of them. For example after a Dispatcher creates a release by pressing the release button it is not sent to stations until after the [Load Report] is generated by AERODATA. In the meantime the Dispatcher could leave the flight to look at other things. However this releases the Dispatcher lock on the flight plan and the system will take liberty in changing parameters of the flight plan. If the Dispatcher were to return to the flight and not catch that there were changes made the Dispatcher could submit Release 1 with changes they were not aware of to the station to print. The system should not be able to make changes to the release after the Dispatcher has pressed release and creating a version of the flight plan. However whether that was the case in this this instance is probably not likely. However terrain page didn't even match the points presented in the remainder of the release [Flight Plan] legs page. The system creating paperwork that doesn't agree with itself is not OK and indicates a lack of robust programming and verification of data. Either way the system should be hardened and known vectors for the generation of incorrect paperwork locked down.
Data retrieved from NASA's ASRS site and automatically converted to unabbreviated mixed upper/lowercase text. This report is for informational purposes with no guarantee of accuracy. See NASA's ASRS site for official report.