In the first part we saw the differences between creative writing and technical writing. We also looked at the purpose and importance of flight manuals. In this second and concluding part I will bring out the best practices, the problems I faced and lessons learnt while authoring flight manuals.
Best Practices.
Flight manuals must be externally compatible with regulations, equipment manufacturers’ requirements (OEMs), and human factors principles and should be internally consistent with the other documents like maintenance and training documents.
A big part of flight manuals covers procedures, but those procedures should be developed in concert with an operator’s philosophy and policies. The philosophy, policies and operational environment should then be used to guide the tailoring of procedures to make them both operationally relevant and beneficial to flight crews.
Procedures should be specific, concise, and unambiguous.
Time critical procedures in flight are of primary importance.
The flight manuals and procedures should be reviewed and tested by the user under real-time conditions on the flight deck or in a simulator.
The procedures affect the degree of crew compliance and overall crew performance.
Guide flight crew with automation procedure so that mission is accomplished along with desired safety.
Specify the document structure at its beginning by explaining organizing elements such as headings, main parts of the document, numbering scheme and other sources of coding or grouping. Use a clear heading system to help users access the needed information and navigate through the document. Placement on page, indenting, numbering schemes, upper vs. lower case letters, font style, color, or size all may be used to show the heading hierarchy, which should be applied consistently. Sequence information based on the following three criteria: 1) Critical information should be placed early and prominently, 2) Actions should be sequenced chronologically, and 3)Items should be sequenced alphabetically, by quality or by quantity.
Lessons Learnt.
As an operator, the Project team defined high level primary and secondary roles of the military aircraft. We developed mission profiles and objectives; stating how the operation will be conducted. We were able to highlight the unique and most positive aspects of the mission along with safety policies. It is the philosophy, policies, operational environment and user needs that ultimately shaped procedures and the organization of operating documents. It helped us modify specific manufacturer-supplied procedures to conform with policy. High-level philosophy of design and logic were highlighted in the flight manuals along with most positive aspects to facilitate HOTAS concept and HMI.
During aircraft upgrade, a lot of new systems were added/replaced which ensued enhanced or additional operational capabilities. Original equipment manufacturers provided the required information for the operation. It was our task to take that information and make sure that it was integrated with the rest of the documents to meet operational requirements.
We also standardize the documentation and procedures with other military aircraft especially of Russian origin operated by the Indian Air Force. Standardizing procedures and flows considerably reduce flight crew training costs and the interoperability of aircraft. It also facilitates easy communication and learning across the fleet.
Economical and precise use of language is essential. Terms must be clear and commonly understood by the flight crew and technicians. It was our aim to ensure standard writing style, terminology, use of graphics, and formatting across documents. We were concurrently working on 7 Volumes of flight manuals that comprised of more than ten thousand pages. A large number of translators were working on the project, and consistency in translation was our biggest worry. The list of abbreviations and ICAO terminology was agreed and finalized. However, the use of similar terms was still a possibility, for example, the terms “throttles” and “thrust levers”; “landing gear” and “undercarriage” refer to the same item. It took a while for the team to choose one term and use it consistently throughout the document. We also insisted that checklists should be consistent with the labeling on the switches and controls on the flight deck.
Flight manuals for military aircraft are driven by operational constraints and are further shaped by the large amount of information that is put in them. It was not practical to place all required information in one document hence grouping criteria were used based on roles for which aircraft was designed and the importance of information. The manuals were divided under the following groups
- Time Critical – e.g QRH, checklist and emergency procedures
- Mission Critical – As per the high-level role and missions defined by Indian Air Force
- Must know – affects the level of safety or delays the operations
- Should know and Could know.
Checklists are critical and most frequently used information on any aircraft. Onboard a fighter aircraft all checks are carried out from memory. Special care was taken in designing them with the use of mnemonics, common geographic organization (left to right or top to bottom) for ease of remembering, and keeping them short and sweet. Most critical items of the checklist were listed as close as possible to the beginning of the checklist to reduce the likelihood of their interruption. These precautions obviated the likelihood of error, reduced workload, and more efficient use of time. Thus enhancing time management and efficiency.
Procedures were designed after careful task analysis to enhance the effectiveness and efficiency of the crew operation. Task analysis considered crew limitations, workload, and system human-machine interface (HMI). Keeping in mind single occupancy, multi-tasking involved, it was a challenge to develop procedures with adequate feedback that was not too complex or too tightly linked to success. For example- Airborne interception radar and electro-optical sensors could be employed simultaneously in different roles for targetting. This was a complex task that could be carried out with proficiency because HMI philosophy and automation logic were adequately conveyed to the flight crew.
Flight deck automation has a range of effects on the system of procedures, some not fully understood. In general, automation leads to the reduction of the overall number of procedures by eliminating some of the actions required by flight crews, but automation may obscure some actions and complicate some decisions. As covered earlier a systematic approach was followed to convey automation philosophy to flight crews. The default selection of various navigation tasks and combat tasks were defined to reduce pilot workload and ease operation while enhancing mission accomplishment. For example, when selecting air to air mode, AI radar was default sensor with pre-defined search volume. Close combat mode was topmost mode and it switched cyclically between different sensors with HOTAS.
Planning and review of manuals is a continuous process and must be carried out at each stage whenever new information is available or new procedure is designed. For procedures and checklists, when the operator has deviated significantly from the manufacturer’s recommendations, the procedure should be validated in a flight simulator. Repeated validation may be required to exercise all relevant operational scenarios (for example, SEAD mission at low-level by night or engine fire immediately after takeoff), and to exercise all possible decision alternatives in a procedure or checklist. Normal procedures and checklists should additionally be validated. This was of great value and importance.
Conclusion
The flight manuals should be:
- Pilot oriented
- Easy and practical to access and use
- Easy to understand
- Accurate and dependable
- Self-contained and self-sufficient
- Stable (avoiding too frequent changes, unless they are considered critical)
Be safety concious. Be safe.
To read Part 1, please click here.
Photo courtesy: https://defenceupdate.in
