Patent ID: 12195196

DETAILED DESCRIPTION

The following detailed description is merely exemplary in nature and is not intended to limit the invention or the application and uses of the invention. As used herein, the word “exemplary” means “serving as an example, instance, or illustration.” Thus, any weather or flight display system or method embodiment described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments. All the embodiments described herein are exemplary embodiments provided to enable persons skilled in the art to make or use the invention and not to limit the scope of the invention which is defined by the claims.

Embodiments of the present disclosure may be described herein in terms of functional and/or logical block components and various processing steps. It should be appreciated that such block components may be realized by any number of hardware, software, and/or firmware components configured to perform the specified functions. For example, an embodiment of the present disclosure may employ various integrated circuit components, e.g., memory elements, digital signal processing elements, logic elements, programmable logic arrays, application specific integrated circuits, look-up tables, or the like, which may carry out a variety of functions under the control of one or more microprocessors or other control devices. In addition, those skilled in the art will appreciate that embodiments of the present disclosure may be practiced in conjunction with any number of systems, and that the systems described herein is merely exemplary embodiments of the present disclosure.

As mentioned, “Fix” is a generic name for a geographical position, and in various contexts, a fix may also be referred to as an intersection, a reporting point, a waypoint, or the like. In operation, aircraft display systems are often limited to displaying the fix information provided by a navigation database (NavDB) that is updated on a prearranged, scheduled, cycle. A technical problem can occur when a pilot wants to add, delete, or modify an airport or airport feature in real-time, during operation of the aircraft.

A technical solution is disclosed herein in the form of systems and methods for a user to define a custom fix via a graphical user interface (GUI) for operation of an aircraft. Proposed embodiments provide a custom database (custom DB120,FIG.1) and one or more custom fix dialog box comprising GUI objects, for creating, editing, and deleting a fix during operation of the aircraft. The provided custom DB is configured to accommodate, for a given fix, the type and amount of data relevant to fully define it as it would be in the navigation database, and the provided GUI dialogue box adapts to each type of fix accordingly.

While the following exemplary embodiments are discussed in terms of an aircraft in flight, it should be appreciated that other embodiments may be employed in other contexts that currently rely on a regulated, periodically updated navigation database.

FIG.1is a block diagram of a system for a user to define a custom fix via a graphical user interface (GUI) for operation of an aircraft (shortened herein to “system”102), in accordance with an exemplary and non-limiting embodiment of the present disclosure. The system102may be utilized onboard a mobile platform to provide calibration of displayed synthetic images, as described herein. In various embodiments, the mobile platform is an aircraft100, which carries or is equipped with the system102. Aircraft100may be any type of vehicle that can travel through the air (i.e., without physical contact with terrain or water). As such, aircraft100may be any type of airplane (regardless of size or propulsion means, ranging from large, turbine-powered commercial airplanes to small, electrically-powered drones), rotorcraft (helicopter, gyrocopter), lighter-than-air vessel (hot-air balloon, blimp), or glider, for example. Aircraft100may be “manned” in the conventional sense that the flight crew is present within the aircraft100, or it may be manned remotely.

As schematically depicted inFIG.1, system102includes the following components or subsystems, each of which may assume the form of a single device or multiple interconnected devices: a controller circuit104operationally coupled to: a HMI106(human-machine interface); a communications circuit108; an avionic display system114; one or more on-board systems and sensors30; and, the custom DB120. In various embodiments, the controller circuit104communicates with the other components of the system102via a communication bus105.

The human-machine interface, HMI106, may include a display device20and a user input device (UI)24. In various embodiments, the HMI106includes at least one instance of an integration of the user input device24and a display device20(e.g., a touch screen display). In various embodiments, the HMI106may include a user input device24such as, any combination of a keyboard, cursor control device, voice input device, gesture input apparatus, or the like.

The avionic display system114is configured to receive and process information from various on-board aircraft systems, sensors, and databases (supplied via the communication bus105), perform display processing and graphics processing, and to drive the display device20to render features in one or more avionic displays22. The term “avionic display” is defined as synonymous with the term “aircraft-related display” and “cockpit display” and encompasses displays generated in textual, graphical, cartographical, and other formats. In various embodiments, the avionic display22is a primary flight display (PFD) or a navigation display. In various embodiments, the avionic display22can be, or include, any of various types of lateral displays and vertical situation displays on which map views and symbology, text annunciations, and other graphics pertaining to flight planning are presented for a pilot to view.

As is described in more detail below, the avionic display22generated and controlled by the system102can include graphical user interface (GUI) objects and alphanumerical input/output displays of the type commonly presented on the screens of MCDUs, as well as Control Display Units (CDUs) generally. Specifically, embodiments of avionic displays22include one or more two dimensional (2D) avionic displays, such as a horizontal (i.e., lateral) navigation display or vertical navigation display; and/or on one or more three dimensional (3D) avionic displays, such as a Primary Flight Display (PFD) or an exocentric 3D avionic display.

Accordingly, the display device20may be configured as a multi-function display (MFD) to include any number and type of image generating devices on which one or more avionic displays22may be produced. The display device20may embody a touch screen display. When the system102is utilized for a manned aircraft, display device20may be affixed to the static structure of the Aircraft cockpit as, for example, the aforementioned Head Up Display (HUD) unit, or a Head Down Display (HDD). Alternatively, display device20may assume the form of a movable display device (e.g., a pilot-worn display device) or a portable display device, such as an Electronic Flight Bag (EFB), a laptop, or a tablet computer carried into the Aircraft cockpit by a pilot.

In various embodiments, the HMI106further includes or has integrated therein an audio system capable of emitting speech and sounds, as well as of receiving speech input. In various embodiments, the HMI106may include any of: a graphical user interface (GUI), a speech recognition system, and a gesture recognition system. Via various display and graphics systems processes, the controller circuit104and avionic display system114may command and control the generation, by the HMI106, of a variety of graphical user interface (GUI) objects or elements described herein, including, for example, tabs, buttons, sliders, and the like, which are used to prompt a user to interact with the human-machine interface to provide user input, and to activate respective functions and provide user feedback, responsive to received user input at the GUI object.

The on-board systems and sensors30generally include a position-determining system110, a sensor system112, a navigation database (NavDB)116, and a flight management system (FMS)118.

The position-determining system110may include a variety of sensors and performs the function of measuring and supplying various types of aircraft status data and measurements to controller circuit104and other aircraft systems (via the communication bus105) during aircraft flight. In various embodiments, the aircraft status data includes, without limitation, one or more of: inertial reference system measurements providing a location, Flight Path Angle (FPA) measurements, airspeed data, groundspeed data (including groundspeed direction), vertical speed data, vertical acceleration data, altitude data, attitude data including pitch data and roll measurements, yaw data, heading information, sensed atmospheric conditions data (including wind speed and direction data), flight path data, flight track data, radar altitude data, and geometric altitude data. The position-determining system110may be realized as one or more of a global positioning system (GPS), inertial reference system (IRS), or a radio-based navigation system (e.g., VHF omni-directional radio range (VOR) or long-range aid to navigation (LORAN)), and it may include one or more navigational radios or other sensors suitably configured to support operation of the aircraft100.

In some embodiments, the position-determining system110may also obtain and/or determine the heading of the aircraft100(i.e., the direction that aircraft100is traveling relative to some reference) using a magnet compass or a magnetometer, for example. The position-determining system110may also include a barometric altimeter such that the position of the aircraft100may be additionally determined with reference to a barometric altitude. In some embodiments, the GPS may alternatively or additionally provide altitude information as part of the position-determining system110. As such, in an exemplary embodiment, the position-determining system110is capable of obtaining and/or determining the instantaneous position and altitude of the aircraft100, and the position-determining system110generates aircraft status data for the aircraft, including the current location of the aircraft100(e.g., the latitude and longitude) and the altitude and heading of the aircraft100. The position-determining system110may provide this aircraft status data to the controller circuit104and the flight management system (FMS)118to support their operation, as described herein.

The sensor system112, as used herein, is a forward-facing sensor system mounted on the mobile platform100, configured to obtain real-time sensor images. During aircraft operation at an airport, the sensor system112provides a sensor image frame depicting airport features surrounding the aircraft position and location. Non-limiting examples of the sensor system112include a camera, EVS Infrared, and millimeter wave system. In some embodiments, the sensor system112includes a camera and associated circuitry, and the sensor image frame is then a camera image frame. In various embodiments, output from the sensor system112additionally includes a frame rate.

In practice, the navigation database116and custom DB120may be realized as two of two or more different onboard databases, each being a computer-readable storage media or memory. In various embodiments, onboard databases store two- or three-dimensional map data, including airport features data, geographical (terrain), buildings, bridges, and other structures, street maps, including the navigational databases116. Specifically, the data stored in the navigation database116may be regulated and periodically updated, as directed by a regulating entity, whereas the custom DB120is managed and updated by the present systems and methods, and is therefore able to adapt to changes more quickly.

FMS118provides the primary navigation, flight planning, and route determination and en route guidance for the aircraft100. The FMS118may contribute aircraft status data provided to controller circuit104, such as, the aircraft's current position, attitude, orientation, and flight direction (e.g., heading, course, track, etc.), the aircraft's airspeed, ground speed, altitude (e.g., relative to sea level), pitch, and other important flight information if such information is desired. In various embodiments, FMS118may include any suitable position and direction determination devices that are capable of providing controller circuit104with at least an aircraft's current position (e.g., in latitudinal and longitudinal form), the real-time direction (heading, course, track, etc.) of the aircraft in its flight path, and other important flight information (e.g., airspeed, altitude, pitch, attitude, etc.). FMS118and controller circuit104cooperate to guide and control aircraft100during all phases of operation, as well as to provide other systems of aircraft100with flight data generated or derived from FMS118.

It should be appreciated that aircraft100includes many more additional features (systems, databases, etc.) than the illustrated systems106-118. For purposes of simplicity of illustration and discussion, however, the illustrated aircraft100omits these additional features.

External sources50may include a weather subscription service, other subscription service, traffic monitoring service, neighbor traffic, air traffic control (ATC), ground stations, and the like.

The term “controller circuit,” as appearing herein, broadly encompasses those components utilized to carry-out or otherwise support the processing functionalities of the system102. Accordingly, in various embodiments, the controller circuit104can be implemented as a programmable logic array, application specific integrated circuit, system on a chip (SOC), or other similar firmware, as well as by a combination of any number of dedicated or shared processors, flight control computers, navigational equipment pieces, computer-readable storage devices (including or in addition to memory7), power supplies, storage devices, interface cards, and other standardized components.

In various embodiments, as depicted inFIG.1, the controller circuit104is realized as an enhanced computer system, having one or more processors5operationally coupled to computer-readable storage media or memory7, having stored therein at least one novel firmware or software program (generally, computer-readable instructions that embody an algorithm) for carrying-out the various process tasks, calculations, and control/display functions described herein. The memory7, may include volatile and nonvolatile storage in read-only memory (ROM), random-access memory (RAM), and keep-alive memory (KAM), for example. KAM is a persistent or non-volatile memory that may be used to store various operating variables while the processor5is powered down. The memory7may be implemented using any of a number of known memory devices such as PROMs (programmable read-only memory), EPROMs (electrically PROM), EEPROMs (electrically erasable PROM), flash memory, or any other electric, magnetic, optical, or combination memory devices capable of storing data, some of which represent executable instructions, used by the processor5.

During operation, the controller circuit104, and hence the processor5, may be programmed with and execute the at least one firmware or software program (for example, program9, described in more detail below) that embodies an algorithm for receiving, processing, enabling, generating, updating and rendering, described herein, to thereby perform the various process steps, tasks, calculations, and control/display functions described herein.

Controller circuit104may exchange data, including real-time wireless data, with one or more external sources50to support operation of the system102in embodiments. In this case, the controller circuit104may utilize the communication bus105and communications circuit108.

In various embodiments, the communications circuit108includes the hardware and software to support one or more communication protocols for wireless communication between the processor5and external sources, such as satellites, the cloud, communication towers and ground stations. In various embodiments, the communications circuit108supports wireless data exchange over a communications network, such as a public or private network implemented in accordance with Transmission Control Protocol/Internet Protocol architectures or other conventional protocol standards. Encryption and mutual authentication techniques may be applied, as appropriate, to ensure data security. In various embodiments, the communications circuit108supports communication with technicians, and/or one or more storage interfaces for direct connection to storage apparatuses. In various embodiments, the communications circuit108is integrated within the controller circuit104.

Turning now toFIG.2, and with continued reference toFIG.1, an architectural block diagram of one or more application modules that may be operating in the system102is described. In various embodiments, each application module inFIG.2is embodied as a processing block of software (e.g., program9) that is configured to cause the processor5to perform the tasks/processes described herein.

An avionic display module202, as may be located in the avionic display system114on an aircraft, receives, from various on-board systems and sensors30, an aircraft position, an aircraft attitude and aircraft orientation data, performs the aforementioned display processing and graphics processing, and generates commands and controls to drive the HMI106and display device20to render features in one or more avionic displays22, as is conventional. Embodiments of the disclosed avionic display module202are enhanced over a conventionally operating avionic display module, with the additional functionality based on receiving and processing input from a dialog box generator module208and input from the custom DB120, as described in more detail hereinbelow. For example, at any given time, the provided avionic display module202may render an active avionic display22that includes a fix from the custom DB120and or a custom database window as described herein.

A user selection decode module204receives user selections from the UI device24. As described herein, the user selections are responsive to various prompts and GUI objects displayed on the display device. The user selection decode module204performs decoding of the user input, which means that it receives a user selection and determines when it invokes a custom database window that the system102generates.

A sequencing interpreter module206performs the function of sequencing, which means that it keeps temporal track of the GUI objects that are displayed and the related user selections that are received to convert the user selection(s) into system102functionality, such as, a selected create fix, an edit fix, a function, alphanumeric input, or the like (e.g., a runway, an airport, an edit, identifications and dimensions, a save, etc.). To make the conversion into system102function, the user selection is at least compared to a current custom database window (i.e., a window displayed on the display device20at the time that the user selection was made).

Accordingly, in various embodiments, a flow of user input (the herein referred to user selections) from the HMI106is through the user selection decode module204and the sequencing interpreter module206. Output of the sequencing interpreter module206may be a command input for the dialog box generator module208.

The dialog box generator module208commands the avionic display module to display a custom database tab on an active avionic display, and coordinates and commands the display of various selectable GUI objects on the active avionic display. To perform these functions, the dialog box generator module208may switch between driving a first arrangement of GUI objects and a second arrangement of GUI objects on the avionic display, based on user selections. The dialog box generator module208may also update the first arrangement of GUI objects and/or the second arrangement of GUI objects, responsive to user input flowing from the UI device24.

The sequencing interpreter module206may determine that a user selection has requested that a fix be saved to the custom DB120. In this instance, a saving fix module210may organize the user unput into a string of associated data fields to save the string in the custom DB120. The string of associated data fields may vary depending on the type of fix. For example, the minimum data fields required for entry of a custom airport fix are Airport identification, position, elevation and magnetic variation. The magnetic variation is automatically populated by the system102from a magnetic variation database that is part of the onboard systems and sensors30. This magnetic variation cannot be modified as like other data. In another example, the minimum data fields required for entry of a custom runway fix are: the runway threshold position, heading, runway touch down zone elevation, runway threshold crossing height and runway length. In various embodiments, a runway fix is further defined by any combination of the following optional data fields: runway width, takeoff/landing threshold and a slope. In various embodiments, runway threshold crossing height, takeoff/landing threshold and slope may have pre-defined default values. The associated airport is automatically populated by the system102and cannot be modified.

Turning now toFIGS.3-5, the graphical representation of a custom database tab (FIG.3,302) on an active avionic display (FIG.3,300) and various selectable GUI objects and their arrangements are illustrated. While the images inFIGS.3-5are not to scale, the relative sizes and locations of the GUI objects is deliberate and can be relied upon. The arrangement of the GUI objects has been designed to be easy on the eye for a user, the labels are designed to enhance speed and ascertainment of associated functions. Additionally, provided embodiments employ an algorithm that has specific sequencing to enhance ease of use and cognition by the pilot. Collectively, these aspects of the present disclosure deliver an objectively improved HMI106.

InFIG.3, an active avionic display300is rendered on a multifunction display (MFD) device, the avionic display having a custom database tab302. Responsive to receiving a user selection of the custom database tab302, the system102renders a custom database window303having a first arrangement of GUI objects. The first arrangement of GUI objects presenting a first selectable GUI object304for selecting between a custom airport and a custom runway. In various embodiments, a second selectable GUI object306further enables selecting between “create” and “edit” functions for a custom fix (in the example, GUI object306is labeled, “create/edit custom Wpt/Arpt/Rwy”). In various embodiments, the custom database tab302also includes a “view details” button306, a “delete” button308, and a “delete all custom fixes” button310. Responsive to a user selection of “custom airports” with GUI object304, the delete button308may further be demarked “delete airport”, and the delete all custom button310may further be demarked “delete all custom airports.”

Responsive to receiving a user selection of GUI object304, the system102displays a second arrangement of GUI objects in the custom database window, the second arrangement of GUI objects having an airport tab402and an associated airport dialog box, the airport dialog box extends a width401and a height403, which the system102will scale to a viewing area on the display device20. The airport dialog box includes a GUI object404for a user to select either new or edit, and a unique GUI object for displaying each of: an airport identification406, an airport position (Lat and Lon)408, an airport bearing410, and an airport elevation412. The airport dialog box further including a GUI object to “save”414.

The second arrangement of GUI objects comprises three columns of rectangular buttons. The three columns have equal width, and all buttons extend essentially across the width of the column that they are in. When buttons have multiple functionalities, ins some embodiments, the multiple functionalities may be toggled between by user input, such as, by selecting the button multiple times. For example, selecting GUI object404once may activate the “new” functionality and the system102may display a visual icon (a radio button of a highlighted color, in the example) to show that “new” is selected. Selecting GUI object404a second time may activate the “edit” functionality and the system102may display a second visual icon (a radio button of a highlighted color, in the example) to show that “edit” is selected.

In an example, the system102receives a user selection of new at GUI object404. The system102updates the airport dialog box in the custom database window (see,416) responsive to receiving associated user input for each of the airport identification, the airport position, the airport bearing, and the airport elevation, this is referred to or defined herein as creating a first custom fix. In the example, the system102receives a user selection of save414after creating the first custom fix and updating the dialog box accordingly. The system102then saves this user input custom airport. The updated airport dialog box418displays a message420that alerts the user that the custom airport was saved. Saving the custom fix means saving it in the custom DB120. Recall, the avionic display module202has access to the custom DB120.

In various embodiments, the second arrangement of GUI objects further includes a runway tab422. In various embodiments, the second arrangement of GUI objects further includes a waypoint tab424. Responsive to receiving a user selection of the runway tab422, the system102displays a runway dialog box502on the custom database window.

The runway dialog box502comprises an arrangement of the following selectable GUI objects: a GUI object for an associated airport504, a GUI object506. In various embodiments, GUI object506enables a user to select between new, edit, and navigation database (NavDB) options. In other embodiments, the GUI object506enables a user to select between new and edit options. The runway dialog box502comprises a unique GUI object for displaying each of: a runway identification508, a runway length510, a runway width512, a runway elevation514, a runway heading516, and a runway threshold position518. The runway dialog box502further includes a selectable GUI object520to save entries as a custom fix.

In an example, the system102updates the runway dialog box522on the MFD device20responsive to receiving a user selection of new, and a user selection of an associated airport (“APT1” inFIG.5), followed by associated user input for each of the runway identification, the runway length, the runway width, the runway elevation, the runway heading, and the runway threshold position, which is referred to as creating a second custom fix, the second custom fix being the runway RW01L inFIG.5. Responsive to receiving a user input of save520, the system102saves the second custom fix to the custom DB120. It may be appreciated that, while the example has a custom airport as a first custom fix and a custom runway as a second custom fix, in practice these can be in the opposite order, and the terms “first” and “second” are only used to distinguish them from each other.

A user can also edit the saved custom runway (or second fix), by selecting edit in the GUI object506. After selecting edit, the user may change the associated airport by selecting the GUI object for an associated airport504, which, in the example, opens as a pull down or scroll window (GUI object526in runway dialog box528). In the example provided, the user intends to edit the newly created runway RW01L (the second custom fix in this example) by associating it with “KPHX” as the airport. The system102updates the runway dialog box528on the avionic display responsive to user input edits, these actions are collectively referred to as editing the second custom fix. Responsive to receiving a user selection of save520, the edited second custom fix is saved to the custom DB120.

From the runway dialog box, a user can also create the new custom runway for an existing NavDB airport by selecting NavDB in the GUI object. After selecting NavDB, a user can also create or edit a new custom runway as a custom fix16for an existing NavDB airport with the system102. In an example, by selecting NavDB in the GUI object506, selecting/updating the airport, and editing the runway data fields in the runway dialog box530, these actions are then followed by the user entered edits and user selection of “save.” In the example, the system102saves the custom fix displayed in runway dialog box530, as associated with the updated airport, in the custom database120.

In an example, the system102receives a user selection of the NavDB option, after having performed the updating to the runway dialog box with the second custom fix; next, the system102receives a user edit to an airport field in the runway dialog box, the user edit changing a NavDB airport to an updated airport; next, the system102receives a user selection of save after receiving the user edit to the airport field in the runway dialog box; and then, the system102saves (into the custom DB120) the second custom fix as a new runway at the updated airport, responsive to the user selection of save.

Returning toFIG.3, and with continued reference toFIGS.4-5, the system102enables a user to delete a custom fix from the custom DB120by selecting the GUI object delete button308. In various embodiments, responsive to a user selection of the delete button, the system102may render a query asking the user to confirm the delete request by selecting a GUI object confirm button. In various embodiments, responsive to a user selection of the “view details” button306, the system102displays, on the first arrangement of GUI objects, an alphanumeric field presenting custom airport or custom runway information. The system102also enables a user to delete all of the custom fixes created by selecting the GUI object310. The system102will clear contents of the custom DB120responsive to the user selection of the delete all custom fixes GUI object. In various embodiments, the system102may prompt the user to confirm the delete all request before proceeding to clear the contents of the custom DB120.

In various embodiments, the avionic display22may be a waypoint list window, an instrument navigation (INAV) display, and a flight planning display. Provided embodiments of the system102support each of these avionic displays22; the system102performs the above described processing steps and once the custom fix dialog box is invoked (i.e., the runway dialog box, e.g.502, or airport dialog box e.g.,416), the system102will display the custom fix dialog box and respond to user selections, and the sequences of user selections, as described above.

For example, on a waypoint list window of the MFD, the system102may display an “amend route” option in a waypoint task drop-down menu. From there, the user may define a custom runway (for example, “RW01L”) in a temporary flight plan; responsive to this, the system102overlays a custom fix box for RW01L on the displayed waypoint list. The custom fix box for RW01L has the same look and arrangement of GUI objects as what has been described above, e.g., the runway dialog box502. Responsive to the user activating the temporary flight plan once it has been created with the custom runway, the system102inserts the custom runway into the active flight plan as an en route waypoint. On the waypoint list, a pilot can use a “change destination” option displayed by the system102to change the active destination to a new custom runway.

Likewise, on an INAV display, the system102may display a “Show” function key, which when selected, opens a “show” dialog box. The pilot may define a new runway by entering a runway identifier in an “enter identifier” field in the “show” dialog box. Responsive to this, the system102again overlays or renders the custom fix box, and the user proceeds to define the custom runway in the custom runway dialog box generated by the system102, as described in connection with the other avionic displays22, above. Likewise, the system102may generate and overlay the various custom dialog boxes on a flight plan avionic display.

Turning now toFIG.6, and with continued reference toFIGS.1-5, a flowchart of a method600for calibrating a synthetic image on an avionic display in a cockpit of an aircraft is described, in accordance with exemplary embodiments of the present disclosure. For illustrative purposes, the following description of method600may refer to elements mentioned above in connection withFIGS.1-5, for example, the tasks/operations may be performed by the controller circuit104. In practice, portions of method600may be performed by different components of the described system. It should be appreciated that method600may include any number of additional or alternative tasks, the tasks shown inFIG.6need not be performed in the illustrated order, and method600may be incorporated into a more comprehensive procedure or method having additional functionality not described in detail herein. Moreover, one or more of the tasks shown inFIG.6could be omitted from an embodiment of the method600as long as the intended overall functionality remains intact.

At602, the system102may be initialized. Initialization may include checking subscription status and synchronizing with a remote site that manages the custom DB120. In various embodiments, having an initialized system102implies that previously generated custom fixes, whether by the same pilot or by other pilots, are present at the beginning of flight operation.

At604, the system102is rendering an avionic display. Avionic displays are described above, in connection with the avionic display module202and avionic display system114. Also, as described above, at604, various embodiments of the system102may display a custom database window on the avionic display. The custom database window has a first arrangement of GUI objects, the first arrangement of GUI objects presenting a first GUI object for selected between custom airports or custom runways, and a second GUI object for selecting between create and edit functions. In various embodiments, the display of the custom database window is responsive to a user selection of a custom database tab that was rendered on the avionic display, as shown inFIG.3.

At606the system102receives user input and selections from the HMI106. At608, as described above, a novel algorithm in the program9decodes and sequences the received user input and selections (e.g., by process modules204and206) to determine which custom fix dialog box to display and when/where to save a custom fix. The output from process modules204and206informs which arrangement of GUI objects is displayed on the avionics display, and which functionality is being performed by the system102, from among at least: display custom fix dialog610, create custom fix dialog612, edit custom fix dialog614, and save custom fix dialog616.

At610, the custom fix dialog box is displayed. The custom fix dialog box may be a custom airport dialog box, as shown inFIG.4, or a custom runway dialog box, as shown inFIG.5. At612, based upon receipt of user input after the custom fix dialog box is displayed, the “create” custom fix dialog box may be generated and displayed. At614, based upon receipt of additional user input, the “edit” custom fix dialog box is generated, displayed, and updated with respective user input. At616, responsive to receiving a user selection of save, the custom fix is saved. After616, the method600may either return to606or604, or end.

Accordingly, the present disclosure has provided several embodiments of systems and methods for a user to define a custom fix via a graphical user interface (GUI) for operation of an aircraft. Provided embodiments enable graphical selection and definition of custom fixes and enable the custom fix to be utilized throughout the avionics system and beyond. The provided embodiments of the custom fix windows work across various avionic displays and various cockpit display systems, electronic flight bags (EFBs), head up displays (HUDs) and cockpit mobile applications. Provided embodiments enable custom fixes that have all required characteristics with regard to existing navigation databases supporting runway overrun alerting, such as ROAAS, capability for the custom runways. Provided embodiments enable the possibility of sharing the custom fixes with customers through connectivity technologies. The custom fix windows provided incorporate human factors reviews of the arrangements of the GUI objects and their size and labels. In summary, the disclosed systems and methods provide an objectively improved HMI over available display systems.

Although an exemplary embodiment of the present disclosure has been described above in the context of a fully-functioning computer system (e.g., system102described above in conjunction withFIG.1), those skilled in the art will recognize that the mechanisms of the present disclosure are capable of being distributed as a program product (e.g., an Internet-disseminated program9or software application) and, further, that the present teachings apply to the program product regardless of the particular type of computer-readable media (e.g., hard drive, memory card, optical disc, etc.) employed to carry-out its distribution.

Terms such as “comprise,” “include,” “have,” and variations thereof are utilized herein to denote non-exclusive inclusions. Such terms may thus be utilized in describing processes, articles, apparatuses, and the like that include one or more named steps or elements but may further include additional unnamed steps or elements.

While at least one exemplary embodiment has been presented in the foregoing detailed description, it should be appreciated that a vast number of variations exist. It should also be appreciated that the exemplary embodiment or exemplary embodiments are only examples, and are not intended to limit the scope, applicability, or configuration of the disclosure in any way. Rather, the foregoing detailed description will provide those skilled in the art with a convenient road map for implementing the exemplary embodiment or exemplary embodiments. It should be understood that various changes can be made in the function and arrangement of elements without departing from the scope of the disclosure as set forth in the appended claims and the legal equivalents thereof.