Investigation of dangerous events in civil aviation is an important task of safety insuring systems. In air transportation, analysis and study of occurrence, of both incidents and accidents play crucial roles in aviation safety. Along with a number of other safety-related techniques, a proper timely-finished investigation makes a huge contribution to preventing future aviation accidents and incidents. A final investigation report, as a result of every single investigation, includes a list of safety recommendations to be implemented by all parties that were involved in an accident, as well as factual information and relevant findings. Obviously, the process of the final report's issuing requires huge effort and time from the investigation's personnel. This paper proposes an approach of automatization of final report generation. An accident study is based on dynamic template-driven algorithms applied in a specific software tool. The proposed algorithm reduces the total work time of personnel for final investigation report generation and increases the effectiveness of the aviation accident investigation bureau operation.
Each occurrence in air transportation which associated with normal airplane operation or could be
hazardous for users of air transportation services reduces the safety of air transportation [
There are many different reasons that could lead to accidents and incident occurrence [
Equipment maintenance and deterioration factors study is an important element in reducing the
occurrence number of dangerous states [
Analysis and detailed study of each aviation event are important components of safety ensuring
in air transportation [
The International Civil Aviation Organization (ICAO) provides support and international control of each investigation activity around the globe. ICAO provides an e-library of detailed reports issued after the finished investigation activity. Database of final reports (FR) nowadays is available in electronic form [17, 18].
Currently, the ICAO database includes more than 1200 FRs of aviation accidents investigation processes provided around the globe and its number will rise eventually. The new reports were added electronically by representative organizations of ICAO member states after finished investigation process. Also, previous paper versions of historical FR could be scanned and added to the database.
Most investigation activity of each event that reduces the safety of aviation is guided by international normative documents and provided by certified agencies in particular member state of ICAO [19]. The core tasks of the investigation process are performed by a team of experts, which could introduce some human factors into the investigation process and may cause some errors [20]. There is a lot of different specific software that helps investigation groups with data analysis, airplane trajectory modeling [21, 22], system fault simulation, and data visualization [23, 24]. Also, there is a specific system that helps to automate most routine tasks during the investigation process which improves the efficiency of the investigated team.
In this paper, specific software for automatic report building based on data available in the database of the aviation accident investigation team is proposed. The automatic report creation system significantly increases the efficiency of report building which includes: time taken to review the intermediate investigator’s report (IIR); formatting IIR, in case of any inconsistency found; returning IIRs to investigators for reworking; compiling and formatting a final version of the report. Automation of the aviation accident investigation’s Final report would reduce time gaps in the process and increase the investigation’s efficiency.
In Ukraine, the National Transportation Investigation Bureau (NTIB) is an authorized authority that may conduct aviation occurrences investigations. NTIB activity is being regulated by national laws and ICAO’s recommendations. NTIB has been testing the Automated Management System for Accidents Investigation (AMSAI) and the FR building module is a part of the automated system.
Classical (manual) or non-automated FR building process in NTIB is shown in Figure 1. During an investigation process, each member of the investigation team interrogates within an investigation group. Each group is focused on a specific direction of investigation by implementing a particular investigation task. An investigator collects evidence which is represented in text notes, photos, and video records. Each investigation task implies the creation of IIR, which consists of facts and a short analysis (if required). Each IIR is being forwarded to a person in charge of FR releasing. Then, a person in charge of FR releasing compiles all collected IIRs, reviews, either approves or returns them for reworking, manually adds their own analysis and conclusions, and, finally, compiles a FR and forwards it to a head of the investigation team for approval.
The structure of FR is standardized by ICAO and should include the following elements: Synopsis, Body, and Appendices [19]. Also, a specific format should be used to send a copy of FR to ICAO. The typical FR format is shown in Figure 2.
Expert 1
Expert N Updating Rework of IIR 1
IIR 1
IIR N Person in charge of
Final report release Compiling, Formatting
Updating Rework of IIR N
An automated management system to support of investigation process and FR building is an important tool to reduce time, minimize human errors, and effective investigation process control.
The first key feature of the suggested approach is to define specific limitations in the process of creating IIR, provided that text and media created by an investigator would meet strict formatting and sequence, so a reviewer would spend less time examining each IIR. AMSAI uses dynamic template-driven forms (TDFs), which are being filled in by investigators. A single TDF unambiguously represents a single IIR and can be related to an investigation group task, investigation task, checklist, or standalone. Core details of the approach are shown in Figure 3.
TDF defines strict rules for its content. It has predefined placeholders for static text with investigation variables; image containers – where a defined number of images can be uploaded; and manual text containers – text blocks that an investigator adds manually. Each TDF is represented in rich-text format [25], which is compatible with HTML format [26] and can be converted in Microsoft .docm format [27]. The latter is being used as FR output format. An investigator is only allowed to upload images and fill in the text fields, whereas AMSAI will store TDF in the internal database. TDF content can be edited by an investigator at any time using a WYSIWYG-compatible editor [28]. Templates of each TDF are created by AMSAI’s administrator, they are stored in rich-text format. Creating FR’s template is the responsibility of the administrator as well. The reason for choosing of .docm format is that this format supports execution of macros [29] that can additionally format an output document after it has been created. Specifically, after FR is created, a special macro is being executed. It analyses the content of FR and builds the Contents page, which is a mandatory part of the document. FR’s template includes static text parts and placeholders for IVs and TDFs. Text parts and placeholders are properly formatted and ordered.
Investigation variables (IV) are represented by pairs of static names and non-static values that depend on the current investigation. They can be enumerated as occurrence class, date, time and state, flight stage, brief circumstances content, place of occurrence, place characteristics, aircraft location, weather conditions, investigation information, search and rescue operations, aircraft type and registration number, operator, owner, pilot-in-command, route and flight number, crew/passengers’ information. IVs can be used either in TDF or in the Final report template itself. The automated Final report-building process is shown in Figure 4. TDF 1
TDF n
TDF 1 TDF n
The algorithm of Final report building can include the following steps: • • • • • • • • • • • • • •
AMSAI’s administrator sets IVs along with evidence and facts are being collected; Investigators fill in TDFs as certain stages of investigation are completed; The head of the investigation commission presses the button “Generate Final report”; TDFs and IVs are being extracted from the database; Each placeholder is being substituted with the corresponding TDF or IV; Contents page is being built;
An output file is created.
Another important feature of the suggested approach is that any TDF or FR’s template can be adjusted by the administrator at any time, providing flexibility in report-building functionality. This can be done from the administrator’s module of AMSAI, which is shown in Figure 5. The container of the editable content, as it is implemented as WYSIWYG rich text editor, allows dynamically creating any HTML content. An administrator can:
Create a formatted content; Insert a placeholder for a predefined occurrence parameter (IV). IVs can be added, deleted, or edited using a specific page in AMSAI’s administrator module; Insert a placeholder of the Contents page; Insert a placeholder for the current date/time; Insert a placeholder for a plain text or image;
Insert a placeholder for a list of abbreviations; • •
Insert page break;
Insert a placeholder for a specific form.
It can be observed, that IVs and TDFs placeholders are represented as links. An example of the HTML code of the IV Flight Stage placeholder is the following: <A href="type=valueFromTable &tableName=INVESTIGATION &fieldName=S_FLIGHT_PHASE_ID &ifNull=null">Value: Flight Phase</A>
The full list of possible types of placeholders is represented in Table 1.
<span style='page-break-after:always'></span>
"<span>" + localdate + "</span>"
abbreviations and text they stand for is stored in the database. The system analyses the entire FR’s text, finds abbreviations matchings, and generates an HTML code of the list, so there is no need to generate the abbreviations list manually; <p>{abbreviation content}</p> For insertion of the Contents page, which is being created by macro; <p>{page content}</p> For insertion of checklist-related TDF; <p>{checklist form content}</p>
<p>{investigation task form content}</p>
<p>{investigation group task form content}</p>
For insertion of a text, entered by investigators. System analyses
attribute “required”, and if it is set to True and the text is empty, an
HTML code with a warning message is generated
If value = True, a CSS [
The reason for choosing a link as a placeholder grounds on following: a link in HTML is represented by a tag <A>. It has a plain text section, which is visible to a user. HREF attribute specifies the URL [26] of a web page the link refers to, and it’s not visible to a user. Hence, the content of this attribute can be used as metadata which AMSAI consumes while rendering FR. Metadata is represented as a set of key/value strings, delimited by the “&” character. The key “type” defines a category of a placeholder.
In case type=”valueFromTable”, a “tableName” and “fieldname” values are used to build an SQL request [30] to AMSAI’s database and extract a value of IV.
Key “ifNull” defines a text that will be rendered in case the value of IV is empty or it cannot be found.
Another type of the placeholder is “form”, which means that specific TDF will be rendered at this placeholder. An example of HTML code is as follows:
<a href="type=form&formId=640& taskId=62& jobId=262&checklistId=null&ifNull=null">Form "62- Study, evaluate and analyze all collected information"</a>
In this case, AMSAI extracts numeric identifiers of corresponding form– “formId”, investigation group task – “taskId”, investigation task – “jobId”, checklist – “checklistId”, builds SQL request, extracts stored HTML code and renders TDF.
Comparing non-automated and automated IIR’s processes, it can be seen that procedures of FR’s formatting and compiling are completely eliminated. Also, the procedures of reviewing don’t include formatting since one is being executed by AMSAI’s report-building module itself. This points out that the procedures of reworking will take less time. Also, static text with IVs placeholders reduces the amount of text being created by the investigators and the person in charge of FR’s release. An example of editing of catastrophe final report template is shown in Figure 5 (in Ukrainian interface only).
In the most complicated investigation, catastrophe, the number of applicable TDFs is 664. It means that the investigators must prepare the same number of IIRs. In addition, in the case of nonautomated FR building a person in charge of FR’s release has to review, reformat, send to rework a huge number of documents, presented in different formats – Microsoft Word, Excel, PDF, jpeg, gif, etc. By using the suggested automation approach, about 80% of mechanical standard routines, like formatting, and writing static text that is not changing and doesn’t depend on investigation type can be skipped and substituted by static text with IVs. Calculating exact numbers is beyond the scope of this paper. However, preliminary analysis of some final reports reveals that 30-35 percent of FR texts are the same. Namely, this fact has come as a ground assumption that all static content can be stored as templates and used in FR automated building. As an example, a Body injuries table has four columns and three rows (Figure 6). Each cell of the table can be filled in with investigation variables, that are defined and stored in AMSAI along with an investigation progress, instead of being created from scratch. As long as new evidence comes up or previous data is changed, there is no need to adjust the table. It will be filled in with valid values and be properly formatted each time a FR is generated. Moreover, automation of such cases allows to avoid typos in text and provide validity of the data.
Obviously, the main part of every Final report still consists of analysis text, provided by investigators manually. The content of analysis parts is under the responsibility of the investigation crew and its reviewing has to be performed only by a human.
The suggested approach of using software that implements dynamic template-driven algorithms allows to significantly reduce the time taken by mechanical standard routines like formatting of Final report parts. It reduces the number of iterations in the process of reviewing and reworking of investigator’s intermediate reports, that the Final report is being composed of. Additionally, Final report templates can be adjusted at any time, providing flexibility in the approach.
In future works we consider application of semantic libraries to analyze the text provided in intermediate investigator’s reports and check content to meet requirements specified in each group’s aims.
The author(s) have not employed any Generative AI tools. [16] M. Quddus, Aviation safety, Air Transport Management. Routledge (2020) 219–237.
doi:10.4324/9780429299445. [17] E-Library of Final Reports, ICAO, 2024. URL: https://applications.icao.int/e5web/default.asp. [18] R. Passarella, Data analysis: the effect of changes that occurred after ICAO standardization on world civil aviations accidents, volume 2. Unsri press, 2021. [19] Aircraft Accident and Incident Investigation. Annex 13 to the Convention on International Civil
Aviation. ICAO, 2020. [20] C. Ng, C. Bil, T. O’Bree, An expert system framework to support aircraft accident and incident investigations, The Aeronautical Journal 125(1289), (2021) 1131–1156. doi:10.1017/aer.2021.11. [21] I. Ostroumov, N. Kuzmenko, Statistical Analysis and Flight Route Extraction from Automatic Dependent Surveillance-Broadcast Data, in: Integrated Communication, Navigation and Surveillance Conference (ICNS), IEEE, Dulles, VA, USA, 2022, pp. i-ix. doi:10.1109/ICNS54818.2022.9771515. [22] N. Kuzmenko, I. Ostroumov, Y. Bezkorovainyi, Y. Averyanova, V. Larin, Airplane Flight Phase Identification Using Maximum Posterior Probability Method, in: 3rd International Conference on System Analysis & Intelligent Computing, SAIC, IEEE, Kyiv, Ukraine, 2022, pp. 1–5. doi: 10.1109/SAIC57818.2022.9922913. [23] M. Zaliskyi, O. Solomentsev, Method of Sequential Estimation of Statistical Distribution Parameters in Control Systems Design, in: 3rd International Conference Methods and Systems of Navigation and Motion Control, MSNMC, IEEE, Kyiv, Ukraine, 2014, pp. 135–138. doi:10.1109/MSNMC.2014.6979752. [24] I.V. Ostroumov, O. Ivashchuk, N.S. Kuzmenko, Preliminary Estimation of war Impact in Ukraine on the Global Air Transportation, in: Proceedings of IEEE 12th International Conference on Advanced Computer Information Technologies (ACIT), Ruzomberok, Slovakia, 2022, pp. 281– 284, doi: 10.1109/ACIT54803.2022.9913092. [25] J. Majumder, S. Sarkar, S. Majumder, Rich Text Programming: A Tool for Code Comprehension, 2015. [26] E. Castro. HTML for the World Wide Web (5th ed.), Peachpit Press, 2003. [27] P. Lagadec, OpenDocument and Open XML security (OpenOffice.org and MS Office 2007), J
Comput Virol 4 (2008)115–125. doi:10.1007/s11416-007-0060-2. [28] TinyMCE documentation. URL: https://www.tiny.cloud/docs/tinymce/latest. [29] Create or Run a Macro-Microsoft Support. URL: https://support.microsoft.com/enus/office/create-or-run-a-macro-c6b99036-905c-49a6-818a-dfb98b7c3c9c. [30] L. Rockoff, The language of SQL. Addison-Wesley Professional. 2021.