1 Introduction

Civil aviation is a rich industry, which is based on constant innovations on technology, organization and practices to improve safety, efficiency, and comfort [1]. Consequently, ICAO and national regulatory organizations have to incrementally develop appropriate standards. Flight crews follow Standard Operating Procedure (SOP) to complete tasks and ensure safety. In abnormal situations such as a malfunction of an aircraft system or extreme weather condition, abnormal procedures have to be used for trouble-shooting.

Operational documentation is regularly improved using experience feedback for normal, abnormal, and emergency situations [2]. The onboard documents can be categorized into four kinds of documents: flying documents, which are related to all flight operations; systems documents, which include systems’ theory, principles, and controls; navigation documents, which are the charts that pilots use on the flight deck; and performance documents, which provide operational data for all flight phases such as takeoff, landing, and go-around [3].

These documents have been paper-based since the beginning of aviation. Today, the concept of an Electronic Flight Bag (EFB) has been developed. “An Electronic Flight Bag is simple and attractive: a pilot’s personal flight-deck computer. Airlines are eager to have customized EFBs on board, and manufacturers are eager to develop and supply them. Software providers are eager to customize software for EFBs as well. There are multiple concepts for what an EFB is, ranging from low-end to high-end devices” [4].

For the last two decades, the shift from paper to electronic documentation has been discussed, modeled, and partly operationalized [5]. This shift is not a matter of transferring paper-based information onto an electronic format (e.g., PDF format). Electronic support offers different kinds of capabilities that paper cannot offer (e.g., context-sensitivity). In other words, onboard paper-based documentation can be connected to flight parameters to provide useful static knowledge, which pilots need to contextualize during operations. Electronic support provides capabilities that enable connectivity, and consequently the provision of dynamic information in context. We claim that electronic documentation, renamed “onboard information system (OIS),” contributes to improving the perception and comprehension of the current situation, as well as supporting decision-making and action-taking.

2 Re-organized Procedures with Respect to Context

The aeronautical community is constantly working on transferring related information from paper to computer support (e.g., Airbus’s Onboard Information System and Boeing’s Electronic Flight Bags). These new tools cover aircraft technical information, operating manuals, performance calculations, and mission management information. They are context-free databases. However, computer support enables interconnectivity among relevant pieces of information (i.e., hypertext links) and between cockpit information and flight parameters (i.e., context-sensitivity) [6].

This dissertation presents a new system, the Onboard Context-Sensitive Information System (OCSIS), which is available on a tablet wirelessly connected to relevant cockpit parameters. OCSIS enables and requires new information formatting (e.g., the concept of page is no longer relevant). In addition, OCSIS’s internal information is structured with respect to context.

“Context is any information that can be used to characterize the situation of an entity. An entity is a person, place, or object that is considered relevant to the interaction between a user and an application, including the user and applications themselves” [7]. Context-aware computing was first discussed by Schilit and Theimer in 1994 as software that “adapts according to its location of use, the collection of nearby people and objects, as well as changes to those objects over time” [8]. Since then, Dey defined “A system is context-aware if it uses context to provide relevant information and/or services to the user, where relevancy depends on the user’s task” [7, 9].

Context patterns can be classified into three categories: independent, hierarchically dependent, and interdependent (Fig. 1) [10]. By a conjunction of situational conditions, the context pattern equals to situational-condition-1, plus situational-condition-2, until plus situational-condition-X. In the sub-context, the relationship can be hierarchically dependent or interdependent.

Fig. 1.
figure 1

Relationship of context islands [10]

Full size image

3 Human-Centered Design Approach

Human-Centered Design (HCD) has been used to incrementally improve OCSIS toward an acceptable mature version (i.e., incremental prototype development, test, and modification) [11]. The model typically represents reality in a simplified way. It proposes important elements and their relevant interconnections in an appropriate, orchestrated manner. The simulation represents the interaction that brings the model to life, which can be used to improve understanding of interactions among different elements that the model implements. It is also used to improve the model itself and eventually modify it (see Fig. 2) [12]. Modeling OCSIS requires pilots’ involvement, and interaction with other onboard systems. The process can be run on a flight simulator, which in turn produces experimental data that could be used to improve OCSIS.

Fig. 2.
figure 2

Human-centered design approach [12]

Full size image

The design of a system is never finished even though at some point, delivery is required. This is why maturity has to be assessed [13]. The more OCSIS is being used and tested, the newer cognitive functions emerge and need to be taken into account either in system redesign, system training, or operations support [12].

During the early stage of design, it is very important to have professional pilots involved to set up a high-level prototype correctly. They need to describe stories applicable to the product being developed and how these historical events may be induced during the product operational phase. This is an important role of participatory design. In the case of OCSIS, professional pilots participated in the design process from the beginning and in all testing sessions (i.e., formative evaluations), providing experience feedback toward improving design.

4 Scenario-Based Design

Scenario-based design requires descriptions of how people use technology, and discussing and analyzing how the technology is used to reshape their activities [14]. It is carried out during the early stages of the design process. During the OCSIS design process, a prototype was incrementally developed and tested by means of using usability principles and criteria.

Scenarios can be abstracted and categorized, helping designers to recognize, capture, and reuse generalizations, and to address the challenges that technical knowledge often lags behind when considering the needs of technical design [15].

Since airlines are allowed to equip tablets on the flight deck to replace heavy manuals and charts, we have chosen to implement OCSIS on a tablet. Another requirement for OCSIS is pilots’ need for assistance in problem-solving under high time-pressure work. In consideration of this important aspect, we developed scenarios that enabled us to test the value of OCSIS in such situations. OCSIS scenarios were developed keeping in mind normal and abnormal situations, as well as training and instructing. We then developed scenarios for the following contexts: (1) Fuel Leak, (2) Descent, (3) Approach, (4) Flaps Locked, and (5) Landing. These scenarios were used in Human-in-the-loop simulations (HITLS) with professional pilots for OCSIS tests. This was the first step of OCSIS’s scenario-based design.

5 Design of OCSIS Prototype

OCSIS is currently programed using Objective-C, an object-oriented language available on Apple’s hardware, on Xcode, the Integrated Development Environment for Objective-C. The first prototype of OCSIS is applying A320 procedures and references. The default/initial page displays procedures and actions that crews need to perform or have performed (see Fig. 3). Parts of normal scenarios are chosen to apply in OCSIS, such as After Start procedures. “Ready to do” actions are in cyan. Once the action is completed and OCSIS can access the related parameters’ status, it automatically becomes “green.” The title of flight phase, normal checklists and more information for actions are in white. Postponed actions or checks and the title of abnormal procedures are in amber [16].

Fig. 3.
figure 3

OCSIS’s normal procedures interface (Color figure online)

Full size image

A menu to select a particular flight phase can be set at the top of the screen. Pilots should be free to move through menus; information flow progress is saved on each page (see Fig. 4).

Fig. 4.
figure 4

OCSIS’s menu

Full size image

  • Procedures: Normal procedures are categorized by flight phases, and a flight phase icon enables manual selection of the current flight phase. Once selected, this icon becomes green automatically. Otherwise, pilots are required to check it into green manually. In the case of an abnormal situation, pilots can select abnormal procedures or stay in normal procedures.

  • Maps: A list of Jeppesen Charts is available. Their sequence can change in real-time with respect to aircraft location.

  • Performance Charts: Four categories of performance charts are available in pdf format: Takeoff Analysis PERF, Inflight PERF, Quick Reference PERF, and FCOM. Pilots can choose charts manually.

  • Flight Plan: The current flight plan is in pdf format for pilots to check and review.

  • Weather Info: Real-time weather is provided to pilots through Internet connection.

  • Manuals: all manuals can be listed in pdf formal. Pilots can refer to any manuals they need.

  • Flight Blog: Pilots can type the problem or observation unusually during the flight for ground maintenance to review and check, include flight date, flight number, departure, arrival, and pilots’ names.

  • Contact Info: The nearby Air Traffic Controller (ATC) contact frequencies are displayed for pilots to get them fast.

The current version of OCSIS includes two abnormal scenarios, “Fuel Leak” and “Flaps Locked”. Context patterns trigger procedures in real-time both in normal and abnormal situations. In an abnormal situation such as “Fuel Leak,” OCSIS will immediately inform the pilot about this malfunction by displaying a pop-up information window (see Fig. 5). Pilots can become aware of the problem through the pop-up window and start following actions, which directs to additional “Fuel Leak” procedures (see Fig. 6).

Fig. 5.
figure 5

“Fuel Leak” triggering

Full size image
Fig. 6.
figure 6

“Fuel Leak” page

Full size image

6 Pilots’ Workload Evaluation

The first series of tests of Onboard Context Sensitive Information System (OCSIS) were carried out in three steps with respect to three main topics: Pilot-OCSIS interaction, situation awareness properties of OCSIS (i.e., OCSIS’s capacity to provide the right information at the right time with the right format – this provides pilots with situated perception and understanding of what is going on and what should be done accordingly), and OCSIS’s location [16]. Based on HITLS from the beginning of the design process, OCSIS was incrementally improved after each test based on the professional pilots’ feedback. With the improved OCSIS set in the simulator (see Fig. 7), pilots’ workload tests were taken in HCDi lab. We invited five pilots to take the experiment. They used paper-based manuals and OCSIS randomly during the experiment in two abnormal scenarios, Fuel Leak and then Flap Locked. Some pilots used manuals for Fuel Leak and OCSIS for Flap Locked, and some pilots used OCSIS for Fuel Leak and manuals for Flap Locked.

Fig. 7.
figure 7

The set of iPad’s location

Full size image

NASA-TLX criteria are used to measure workload in the two sessions to compare [17, 18]. Pilots are required to grade their workload and performance by values from 1 to 10. Based on the grading values collected from four pilots, the overall workload of dealing with each failure is calculated (see Fig. 8).

Fig. 8.
figure 8

Overall workload of pilots (Color figure online)

Full size image

The blue cylinders represent workload by using paper-based documents, and the yellow cylinders represent workload by using the OCSIS under the context of Fuel Leak and Flaps Locked. Analyze the sample mean and standard deviation of pilots’ workload by using two different references (see Table 1), we can find that these five pilots’ workload is less when they used OCSIS in the two abnormal scenarios. As an assistance for pilots during performing procedures, OCSIS can provide them standard information immediately which can save them a lot of time on searching procedures and calculating performance data. However, it still needs plenty of samples to verify if OCSIS can reduce pilots’ workload in more scenarios.

Table 1. Workload analyses
Full size table

7 Discussion

At this point, it is important to mention that this dissertation is not a classical human factors and ergonomics research project where human issues are discovered after engineering work is done (i.e., corrective ergonomics). It is, instead, a human-systems integration project that is based on expert analysis of previous experience provided by accident reports and professional pilot expertise, creative design, iterative usability, usefulness assessments of prototypes using human-in-the-loop simulations involving professional pilots (i.e., formative evaluations), and constant creative (re)design of solutions. These solutions are not only technological, but also organizational and individual (in the sense of job roles and functions). The full capacity and ability of OCSIS will not be compared to current paper-based operational documentation, but this research is going to provide a first contribution to the maturity process of OCSIS design. Formative evaluation helps to correct design flaws form new design decisions. It uses heuristics and is cooperative (i.e., involves real users). This approach is strongly based on a meticulous follow up of design history, which involves purposes (such as the ones deduced from accident analyses, as shown above for example), solutions proposed (including various possible options), and criteria that make design choices possible and effective (including pilots’ activity analysis in human-in-the-loop simulations).

We make a distinction between task (i.e., what is prescribed to be performed) and activity (i.e., what is effectively performed) [10, 13, 19]. Activity analysis is based on direct observation, questionnaires, interviews, and human factors studies. Today, activity analysis is possible because we have realistic modeling and simulation capabilities. It enables us to better understand how human operators execute tasks, and eventually defines emergent activities that are necessary to accomplish their goals. Performing activity analysis during design is one of the most important assets of human-centered design.

8 Conclusion

One of the most critical features of OCSIS is context-sensitivity, which enhances operational procedures following. Context-sensitivity provides pilots with more flexibility in flight operations. The main issue of this approach is the definition of context patterns. Indeed, getting the right procedure at the right time means that the system has the appropriate context pattern that matches the current situation and triggers the appropriate procedure. Consequently, context pattern correctness is crucial. In other words, context patterns have to recognize the right context and propose the right procedure to the pilot [11]. Future work will be dedicated to context pattern acquisition and formalization in the context of OCSIS development.

Creativity and evaluation are two important processes in Human-Centered Design (HCD). Creativity can be seen as integration of existing things [20]. Regarding OCSIS, we integrated well-known technology and techniques to create a new tool [11]. HCD recommends testing activity from the very beginning of design using realistic technology (e.g., realistic operating procedures and aircraft simulator), organization (e.g., two crewmen cockpit organization) and people (e.g., professional pilots). This approach led to very credible simulations, which were used to increase the tangibility of OCSIS (i.e., flexibility, maturity, and stability).

The shift from paper to electronics enables the emergence of context-sensitive HCI. Consequently, representation of context, identification of relevant contextual information, and actual interaction at the right time with the right information are key issues that needed to be further explored and developed. Our approach was based on creativity. We explored various kinds of solutions that attempted to improve safety, efficiency, and comfort on the flight deck. In future work, more scenarios need to be designed on OCSIS and more pilots are needed to take the experiments to improve the system.