Patent Description:
The solution is provided by the features of the independent claims. Variations are as defined by the dependent claims.

In the following detailed description of embodiments of the present disclosure, numerous specific details are set forth in order to provide a more thorough understanding of the inventive concepts. However, it will be apparent to one of ordinary skill in the art having the benefit of the present disclosure that the inventive concepts disclosed herein may be practiced without these specific details. In other instances, well-known features may not be described in detail to avoid unnecessarily complicating the present disclosure.

In addition, use of the "a" or "an" are employed to describe elements and components of embodiments of the present inventive concepts.

Finally, as used herein any reference to "one embodiment" or "some embodiments" means that a particular element, feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the inventive concepts disclosed herein. The appearances of the phrase "in some embodiments" in various places in the specification are not necessarily all referring to the same embodiment, and embodiments of the inventive concepts disclosed may include one or more of the features expressly described or inherently present herein, or any combination or sub-combination of two or more such features, along with any other features which may not necessarily be expressly described or inherently present in the present disclosure.

Aeronautical charts (flight charts) are used by pilots to navigate aircraft during departing and landing phases (e.g., using terminal flight charts) and during en-route phases (e.g., using en-route flight charts). Using flight charts and other tools, pilots are able to determine position of the aircraft, safe altitudes for the aircraft, optimal routes to a destination, navigation aids, alternative landing areas in case of an inflight emergency, and other useful information such as radio frequencies and airspace boundaries. Specific charts are used for each phase of a flight and may vary from a map of a particular airport facility to an overview of the instrument routes covering an entire continent (e.g., global navigation charts).

Electronic chart data is conventionally defined in a digital file format such as portable data format (PDF) by flight chart vendors. Vendors that provide flight charts (e.g., to aircraft system manufacturers, airline pilots, etc.) in the PDF format provide the chart files at a lower cost than competitors. Flight chart users must convert the PDF flight charts to a format usable by aircraft computing devices (which are often limited in processing and memory capacity). Thus, it is desirable to provide a system that processes and converts flight charts such that aircraft computing devices can easily and efficiently retrieve flight chart data.

Embodiments of the present disclosure are directed to a flight chart conversion system that converts flight chart files to a condensed set of hardware directives that may be directly loaded onto aircraft computing devices. The converted flight charts are generated using software tools executed on a host computing device (e.g., a ground-based computing device that is not on the aircraft, such as a personal computer). The converted flight charts are then presented on an aircraft display using a flight chart application (executed using an aircraft computing device).

Flight chart files (graphical images of terminal and en-route charts) are processed on the host computing device into a set of binary images (e.g., images defined using <NUM>-bit aircraft display hardware directives). The aircraft display hardware directives can then be quickly and easily displayed to a pilot. The aircraft display hardware directives may decrease loading times and conserve processing and memory resources. Flight chart metadata may also be generated to enable facile pilot selection and data lookup, and a configuration file may customize the chart conversion process for particular flight displays.

<FIG> and <FIG> are block diagrams illustrating the method steps of a flight chart conversion system <NUM>, in accordance with one or more embodiments of the present disclosure. The method steps of the flight conversion system <NUM> may be stored as program instructions (e.g., software modules) in a memory of one of more computing devices. A chart processing module <NUM> may be executed off-line <NUM> (e.g., not on an aircraft) using a host computing device to generate a flight chart database <NUM> (e.g., converted flight chart data) from one or more flight chart files <NUM>. The flight chart database <NUM> may then be stored on a memory of an aircraft computing device and displayed to a pilot at run-time <NUM> (e.g., when the pilot operates an aircraft).

For example, <FIG> shows the flight conversion system <NUM> including a host computing device <NUM>. Additionally, <FIG> shows an aircraft computing device <NUM> configured to display flight charts using the flight chart database <NUM> (e.g., after the conversion of the flight chart files <NUM> to the flight chart database <NUM>).

The host computing device <NUM> and the aircraft computing device <NUM> may be controllers (e.g., computers), each respectively including one or more processors <NUM>, <NUM> and a memory <NUM>, <NUM>. For the purposes of the present disclosure, the term "processor" or "processing element" may be broadly defined to encompass any device having one or more processing or logic elements, for example, one or more central processing units (CPUs), one or more graphics processing units (GPUs), one or more micro-processor devices, one or more application specific integrated circuit (ASIC) devices, one or more field programmable gate arrays (FPGAs), or one or more digital signal processors (DSPs), etc. In this sense, the one or more processors <NUM>, <NUM> may include any device configured to execute algorithms and/or instructions (e.g., program instructions stored in memory), and may be configured to perform the method steps described in the present disclosure (for example, the method steps described with respect to <FIG> and <FIG>). The memories <NUM>, <NUM> may include any storage medium known in the art suitable for storing program instructions executable by the associated processors <NUM>, <NUM>. For example, the memory mediums <NUM>, <NUM> may include, but are not limited to, a read-only memory (ROM), a random-access memory (RAM), a magnetic or optical memory device (e.g., hard disk), a magnetic tape, a solid-state drive, and the like.

The host computing device <NUM> may be, for example, a personal computer (PC), a laptop, a smartphone, a tablet, a server, a mainframe, etc. In some embodiments, the host computing device may operate using a Microsoft® Windows® operating system, an Apple® macOS® operating system, a Linux-based operating system, etc. In some embodiments, the host computing device may comprise a plurality of computing devices (e.g., a cloud-based system). It is noted that the host computing device <NUM> may be a ground-based computing device (e.g., not a part of an aircraft).

The aircraft computing device(s) <NUM> may comprise one or more avionics embedded systems (e.g., an avionics suite), and may include a flight management system (FMS) computing device, a communications computing device, a navigation computing device, a flight display computing device, a flight control computing device, a fuel management computing device, a collision-avoidance computing device, a weather computing device, etc. It is noted that the host computing device <NUM> may have substantially greater processing and memory resources than the aircraft computing device(s) <NUM>, and that it may be advantageous to implement the chart processing module <NUM> using the host computing device <NUM>. For example, the flight chart files <NUM> required for a typical aircraft flight may have a size of <NUM> GB or more, whereas the memory <NUM> of the aircraft computing device <NUM> may have only <NUM> GB allocated to flight charts.

Referring back to <FIG>, flight chart metadata <NUM>, flight chart files <NUM>, and a configuration file <NUM> may be input into the chart processing module <NUM> to generate a flight chart database <NUM>. The metadata <NUM>, flight chart files <NUM>, and configuration file <NUM> may be stored on the memory <NUM> of the host computing device <NUM>.

The flight chart file(s) <NUM> may be any industry standard flight chart file that includes text. In some embodiments, the flight chart files <NUM> may be portable data format (PDF) flight chart files, comma-separated values (CSV) flight chart files, or scalable vector graphics (SVG) flight chart files. The flight chart files <NUM> may be images representing terminal flight charts, en-route flight charts, nautical charts, world aeronautical charts, sectional charts, airport diagram charts, etc. The images may show topographical features such as terrain elevations, ground features identifiable from altitude (rivers, dams, bridges, buildings, airports, beacons, landmarks, etc.), and information related to airspace classes, ground-based navigation aids, radio frequencies, longitude and latitude, navigation waypoints, navigation routes, airways, taxiways, runways etc..

Each of the flight chart files <NUM> may be associated with respective flight chart metadata <NUM>, which may include flight chart name (e.g., "Omaha Eppley Airfield"), flight chart type (e.g., terminal, en-route, world aeronautical, etc.), flight chart geographical location (e.g., Omaha, Nebraska), etc..

The metadata <NUM> may be defined in Extensible Markup Language (XML). XML is a markup language that defines a set of rules for encoding documents in a format that is both human-readable and machine-readable. The characters making up an XML document may be divided into markup and content, and may be distinguished by the application of syntactic rules. XML strings that constitute markup may begin with the character "<" and end with ">", or begin with the character "&" and end with ";". Strings of characters that are not markup are content. An XML tag may be a markup construct that begins with "<" and ends with ">". Three types of XML tags include: start-tag, such as <section>; end-tag, such as </section>; and empty-element tag, such as <line-break />. An XML element may be a logical document component that either begins with a start-tag and ends with a matching end-tag or includes only an empty-element tag. The characters between the start-tag and end-tag, if any, are the element's content, and may include markup and other elements, which are called child elements. An example is <greeting>Hello, world!</greeting>. Another is <line-break />. An XML attribute is a markup construct consisting of a name-value pair that exists within a start-tag or empty-element tag. An example is <flight_chart name="Omaha Eppley Airfield" type="terminal" location="Omaha, Nebraska"/>, where the names of the attributes are "name", "type", and "location" and their values are "Omaha Eppley Airfield", "terminal", and "Omaha, Nebraska" respectively. An XML attribute may have a single value and each attribute may appear once in each element.

The configuration file <NUM> may be used to define the type of aircraft display configured to display converted flight charts. For example, each type of aircraft display may have a respective resolution (e.g., 1920x1080), pixel density (e.g., <NUM> pixel per inch), aspect ratio (e.g., <NUM>:<NUM>), and screen size (e.g., <NUM> inches diagonally) that differs from other types of aircraft displays. The configuration file <NUM> may also define input and output directories, version numbers, control data (e.g., an option to save temporary files), spatial modulation patterns of the aircraft display, and selection criteria (e.g., such that a pilot can search for a flight chart using a region name, a runway length, etc.). In some embodiments, the configuration file <NUM> is defined in XML. It is noted that the metadata <NUM> and the configuration file <NUM> may be defined in other data formats (for example, JavaScript Object Notation [JSON]).

Referring now to <FIG>, a block diagram illustrating the method steps of the chart processing module <NUM> is shown. The chart processing module <NUM> may be stored in the memory <NUM> of the host computing device <NUM> and executed by the processor <NUM> of the host computing device <NUM>. The chart processing module <NUM> may be substantially similar or substantially identical to the Electronic Chart Application Tool Suite developed by Collins Aerospace (Cedar Rapids, IA). The chart processing module <NUM> may include a plurality of submodules including an extraction module 108a, a preprocessing module 108b, a conversion module 108c, a compression module 108d, and a combination module 108e.

The extraction module 108a may be configured to convert the flight chart file(s) <NUM> to one or more scalable vector graphics (SVG) flight chart files defined in XML. In some embodiments, the SVG flight chart file(s) may be generated by converting PDF flight chart file(s) <NUM> or CSV flight chart file(s) <NUM>. In some embodiments, the flight chart file(s) <NUM> may be SVG flight chart files, and the extraction module 108a may convert the original SVG flight chart file(s) <NUM> to SVG flight chart files having different tags.

SVG is a vector image format for two-dimensional graphics. Since the SVG flight chart file(s) are defined as XML text files, the SVG flight chart file(s) can be searched, compressed, and scaled in size without loss of quality. Each of the SVG flight chart file(s) may be associated with respective metadata <NUM> defined in XML (for example, in an element including a start-tag <metadata> and an end-tag </metadata>).

The preprocessing module 108b may be configured to preprocess the SVG flight chart file(s). Preprocessing the SVG flight chart file(s) may entail simplifying the SVG flight chart file(s) to improve the readability of flight chart(s) stored in the flight chart database <NUM>, and to conserve the processing and memory resources of the aircraft computing device(s) <NUM> that access the flight chart database <NUM>.

For example, the preprocessing module 108b may be configured to remove filled shapes overlapping navigational paths, fixes, and landmarks (to reduce clutter in the images), detect font characters and replace the font characters with font character references (so that all of the flight charts use the same font references when drawing characters which conserves memory capacity since the same font characters are not duplicated for each chart), associate charts with geographic references (e.g., airports, structures, landmarks, etc.), reduce the size of chart elements (to further conserve memory capacity), remove chart elements that are not visible (e.g., removing hidden chart elements to conserve memory capacity), detect repeating patterns (to further conserve memory capacity), and convert chart elements common to all of the flight charts to subroutines (to further conserve memory capacity).

The conversion module 108c may be configured to convert the SVG flight chart file(s) to one or more flight charts defined in one or more sets of aircraft display hardware directives. Each of the set(s) of aircraft display hardware directives is associated with the respective metadata <NUM>. The aircraft display hardware directives may have a <NUM> bit form with <NUM> bits allocated to an opcode (e.g., that specifies a graphic operation to be performed, such as DRAW, MOVE, SETCOLOR) and <NUM> bits allocated to pixel data and pixel address (e.g., color of pixel(s), location of pixel(s), etc.).

The compression module 108d may be configured to compress each of the flight chart(s) and the respective metadata <NUM> (using a data compression algorithm). In this way, the compressed flight chart(s) use fewer bits than the original form, thus further conserving processing and memory resources of the computing devices <NUM>. The compression may be either lossy or lossless. Lossless compression reduces bits by identifying and eliminating statistical redundancy (no information is lost in lossless compression). Lossy compression reduces bits by removing unnecessary or less important information.

The combination module 108e may combine the flight chart(s) and the respective metadata <NUM> into a flight chart database <NUM> (converted chart data). The flight chart database <NUM> may then be loaded onto the memory <NUM> of the of the aircraft computing device(s) <NUM> via, for example, a satellite, cellular, or WiFi internet connection, a USB flash drive, a controller pilot data link (CPDL), etc..

After the flight chart database <NUM> is loaded onto the aircraft computing device(s) <NUM>, a list of flight charts may populate the aircraft display <NUM>, and the pilot or user of the aircraft may then highlight and select a flight chart to present on the aircraft display <NUM>. The flight chart database <NUM> may be searchable using the respective associated metadata <NUM> of the flight chart. For example, the user of the aircraft may search for the name of the flight chart or the name of a geographic reference or chart element associated with the flight chart (e.g., by typing into a search bar presented on the aircraft display <NUM> using a keyboard or touchscreen).

The selected flight chart may then be passed to a chart application module <NUM>. The chart application module <NUM> may render an image based on the selected flight chart using a graphics engine (GE) module. In some embodiments, the chart application module <NUM> may be substantially similar or substantially identical to the Electronic Charts Application (ECA) developed by Collins Aerospace (Cedar Rapids, IA), and the graphics engine module may be substantially similar or substantially identical to the Collins Graphics Engine developed by Collins Aerospace (Cedar Rapids, IA).

The set(s) of aircraft display hardware directives (associated with the selected flight chart) may be passed to a graphics server module <NUM> to be presented on one or more aircraft displays <NUM>. The graphics server module <NUM> may be the interface (e.g., Cockpit Display System [CDS]) between the chart application module <NUM> and the aircraft display(s) <NUM>. The graphics server module <NUM> may be an ARINC661 Graphics Server (AGS) that uses a Display List Data Widget to pass the set of aircraft display hardware directives to the aircraft display(s) <NUM>. ARINC <NUM> may define communication between the graphics server module <NUM> and the chart application module <NUM> (i.e., an avionics computing standard). The graphics server module <NUM> manages one or more Definition Files (DFs) for the chart application module <NUM>. The DFs specify the GUI definition associated with the chart application module <NUM> including one or more layers. A layer (also named User Application Layer Definition or UALD) is a GUI container for widgets, and a widget is the basic building block of the GUI (e.g., Containers, Lists, ScrollPanes, Buttons, Menus, Labels, EditBoxes, etc.).

<FIG> is a flowchart illustrating a flight chart conversion method <NUM>, in accordance with one or more embodiments of the present disclosure. The flight conversion method may be implemented by the flight conversion system <NUM> described with respect to <FIG>.

At step <NUM>, flight chart file(s) are converted to SVG flight chart file(s) defined in XML. Each of the SVG flight chart file(s) may be associated with respective metadata defined in XML. At step <NUM>, the SVG flight chart file(s) may be preprocessed by simplifying the SVG flight chart file(s) to improve the readability of flight charts, and to conserve the processing and memory resources of aircraft computing device(s) that utilize the flight charts. At step <NUM>, each of the SVG flight chart file(s) may be converted to flight chart(s) defined in set(s) of aircraft display hardware directives. Each of the flight chart(s) is associated with the respective metadata. The aircraft display hardware directives may have a <NUM> bit form with <NUM> bits allocated to an opcode and <NUM> bits allocated to pixel data and pixel address. At step <NUM>, each of the flight chart(s) and respective metadata may be compressed (e.g., using a data compression algorithm). At step <NUM>, the flight chart(s) and the respective metadata may be combined into a flight chart database (e.g., converted chart data). The flight chart database may then be loaded onto the memory of the of the aircraft computing device(s).

Claim 1:
A flight chart conversion system (<NUM>), comprising:
a host computing device (<NUM>) including one or more processers (<NUM>) configured to execute program instructions causing the one or more processors to:
convert one or more portable data format, PDF, or comma-separated value (CSV), flight chart files to one or more scalable vector graphics, SVG, flight chart files defined in extensible markup language, XML, wherein the one or more PDF or CSV flight chart files are image files that show:
topographical features, including ground features available from altitude; and
information related to airspace classes, including radio frequencies,
wherein each of the SVG flight chart file(s) is associated with respective metadata defined in XML;
preprocess each of the SVG flight chart file(s), wherein preprocessing each of the SVS flight chart file(s) includes at least:
removing filled shapes overlapping navigational paths, detecting font characters, and replacing the font characters with font character references;
convert the SVG flight chart file(s) to one or more flight charts defined in one or more sets of aircraft display hardware directives, wherein each of the flight chart(s) is associated with the respective metadata;
compress the flight chart(s) and the respective metadata; and
combine the flight chart(s) and the respective metadata into a flight chart database.