WO2017173416A1

WO2017173416A1 - Aviation sector special departure procedure systems and methods

Info

Publication number: WO2017173416A1
Application number: PCT/US2017/025627
Authority: WO
Inventors: Paul Hannah; llYA ROSENFELD; Alec SEYBOLD; Tyler HAWKINS
Original assignee: Netjets Inc.
Priority date: 2016-03-31
Filing date: 2017-03-31
Publication date: 2017-10-05
Also published as: WO2017173417A1

Abstract

Exemplary system and method embodiments described herein are adapted to construct and present sector special departure procedures (SSDPs) for aircraft departing an airport runway under a one or more engine inoperative or other emergency situation. A SSDP divides a bounding area around an airport into sectors and creates various other areas associated with the runway of interest, analyzes, filters and processes obstacles within said areas, and calculates different possible flight paths to different obstacles so as to present the quickest and safest possible return paths to the runway through the various sectors.

Description

AVIATION SECTOR SPECIAL DEPARTURE PROCEDURE

SYSTEMS AND METHODS

Inventors: Paul Hannah

llya Rosenfeld

Alec Seybold

Tyler Hawkins

TECHNICAL FIELD

[0001] Exemplary system and method embodiments described herein are directed generally to facilitating the various required functions of the aviation industry, and more particularly to the development and presentation of sector special departure procedures for aircraft departing an airport. BACKGROUND

[0002] While air travel may seem simple from the perspective of an average passenger, this is actually far from the case. In reality, the business of aviation, both commercial and private, has many complicated aspects that need to properly interact in order to convey the aura of a seamless system. These aspects include, without limitation, airport and air traffic management, flight planning, flight operations engineering, emergency management, aircraft maintenance, and industry (e.g., government) regulation.

[0003] From an infrastructure standpoint, airports generally serve as the mechanism by which aircraft and passengers are able to transit from one location to another. That is, airports receive passengers, serve as the conduit by which passengers connect with the various airline operators, and serve as the point of arrival and departure for airline and private aircraft on a daily basis. Airports are not constructed without substantial forethought and planning, which includes consideration of who and what type of aircraft are likely to use a given airport, as well as how airport operations will and might be someday affected by the surrounding area and surrounding structures. Nor are existing airports or their surrounding areas static in nature - rather, existing airports typically undergo temporary and/or permanent changes that affect the users of said airports. Similarly, the areas surrounding airports may change dramatically over time, whether as a result of human progress or of nature.

[0004] Airport and surrounding area information needs to be made available to operators of aircraft and other affected parties. Likewise, changes to airport information or to surrounding area information also needs to be made available or, more desirably, needs to be disseminated to operators of aircraft and other affected or relevant parties to ensure that said parties are always using the most current information available. This dissemination of information may occur using a number of models including but limited to publish/subscribe, download, socket relay, polling or other methods. In a reverse manner, airport managers and others need to understand the operations and aircraft of the carriers and other users of their airports, whether for the purpose of communicating changes that might affect flight operations, for planning changes to better suit the future needs of those users, or otherwise.

[0005] Commercial and private airline operators and pilots, as well as private pilots and others, have a need for airport information. Airport information is critical to flight planning, not just for purposes of scheduling and general route calculation, but also for more specific purposes such as determining proper landing and takeoff procedures for given aircraft, and for emergency response planning.

[0006] It should be apparent, therefore, that changes to airport information can profoundly affect the determinations that must be made by airline operators and pilots. For example, the erection (or removal) of a tall structure within a certain vicinity of a runway may cause a corresponding change in the flight path to be followed by an aircraft during takeoff from or landing on said runway. It is also possible that a given aircraft (or class of aircraft) may no longer be able to use a runway affected by the erection of a sufficiently tall structure. The growth of trees surrounding an airport may have a similar affect, even if on a more gradual basis. Numerous other examples of relevant changes to airport information also exist, such as without limitation, the shortening or lengthening of a runway or a change in the number or type of navigational aids present. Even temporal events near a given runway may be relevant to personnel engaged in flight planning or the actual piloting of aircraft that will use said runway.

[0007] As with airport information, pilots and other flight operations/planning personnel need access to aircraft performance information. Aircraft performance information is necessary, for example, in order to determine appropriate takeoff and departure procedures for a given runway of a given airport under any number of environmental conditions and aircraft weight and balance scenarios. Aircraft performance information is similarly important in crafting enroute emergency procedures - particularly, but not exclusively, those procedures associated with an engine out on takeoff scenario.

[0008] Surrounding all of the aforementioned aspects of the aviation industry, is regulatory compliance. As one might expect, the aviation industry is heavily regulated. In the U.S., primary regulatory responsibility falls on the Federal Aviation Administration (FAA), which is an agency of the U.S. Department of Transportation that oversees, among other areas of aviation, regulation, certification and safety. Therefore, among other functions, the FAA is involved with airport planning and development projects, as well as airport compliance; is in charge of developing and operating the U.S. air traffic control system; is responsible for the certification of aircraft and for promulgating associated safety practices, developing safety programs and issuing safety alerts; is responsible for certifying airports, airlines and aviation personnel, including pilots and maintenance personnel; and engages in rulemaking and in publishing the Federal Aviation Regulations (FAR) and other policies, guidance, advisories, notices, etc.

[0009] Because of the regulated nature of the aviation industry, it is also important that regulatory personnel have access to accurate and up to date information on airports, airlines and aircraft. Likewise, it is important that other aviation industry personnel such as airport operators, airline carriers and commercial operators, pilots, maintenance personnel, etc., have easy access to the various - and sometimes voluminous - regulatory data relevant to their job function.

[0010] From the foregoing commentary, the importance of information sharing and information access across the various aspects of the aviation industry should be apparent to one of skill in the art. Most basically, information access and information sharing are obviously important simply to ensure that all parties are working with like, and current information. Similarly, access to and notification of changes to such information is also important as it has been explained above how a change in information associated with one aspect of the aviation industry may have a significant impact on one or more other aspects. For example, the benefits associated with the use of even robust and current performance data to calculate the aircraft performance parameters of a given airport departure procedure may be severely diminished if the corresponding airport information is outdated and/or incorrect.

[0011] Problematically, however, there has heretofore been no single system and method capable of accomplishing such functions. Instead, information and changes to information associated with one aspect of the aviation industry frequently remain unknown to other aspects of the aviation industry, or dissemination of such information or changes to information otherwise takes an inordinate amount of time.

[0012] In addition to the aforementioned difficulties associated with information sharing and information access, the resolution of conflicting information has also been heretofore problematic. More particularly, there has been no accepted approach or proffered technique of resolution when information from different sources conflicts regarding the same issue, object, location, or other subject matter. For example, several different data sources may disagree on the precise geographic location of a given obstacle, runway location or some other object or subject of interest and, when they do, there has been no accepted approach to resolving the conflict.

[0013] The benefit, if not need, for an interested party to have access to the various conflicting sources of information should be obvious. Likewise, a system and method for accurately resolving conflicts in aviation, aeronautical and/or geospatial information should be apparent.

[0014] Also problematically, presently known and used systems and methods for accessing, presenting and using aviation, aeronautical and geospatial information are not user friendly, and often only certain personnel are able to understand certain information due to the format and/or complexities of the information and the presentation techniques employed. Consequently, it would also be highly desirable to provide a system and method that simplifies the retrieval, presentation and use of such information in a new, more intuitive, and easy to understand and manipulate manner.

[0015] Currently known techniques for aircraft performance calculation are typically very mathematical, rather than visual, in nature. Currently known techniques for aircraft performance calculation are also typically based on, for example, runway analysis, or are otherwise not procedure based. Similarly, currently known techniques for aircraft performance calculation are typically not risk-based - that is, such techniques are not designed to present a user with the numerical and visual risks associated with the performance calculation such that a user is able to easily understand and visualize the risks associated with a given procedure, with performance, or with weight and balance decisions (i.e., to balance risk and return). Consequently, there is a need for an aircraft performance calculation system and method that is procedure-based, and that also allows a user to easily visualize the risks associated with a given procedure, with performance, or with weight and balance decisions.

[0016] Similarly, currently known techniques for flight (enroute) emergency planning can make such planning very challenging, and it has also been determined that most operators are not currently willing to perform the continued engineering analysis necessary to effectuate proper enroute emergency planning. Therefore, there is a need for a better solution for providing relevant personnel at least with visual feedback regarding the safest paths to take when experiencing an enroute emergency situation. A similar solution for providing relevant personnel with visual feedback regarding special missed approach procedures would also be desirable.

[0017] Exemplary system and method embodiments described herein solve these and other problems, and additionally offer a novel approach to the manner in which aviation, aeronautical and/or geospatial information is presented to a user.

SUMMARY

[0018] Exemplary system and method embodiments described and depicted herein are directed generally to facilitating the various required functions of the aviation industry. To this end, exemplary system and method embodiments will typically have an aeronautical/geospatial database, or series of databases, containing information relating to, for example and without limitation, airports, runways, terrain and obstacles, land use, land cover, navigational aids, communications infrastructure, etc. Other system components may utilize the information from this database(s) to provide users with answers to queries relating to, for example and without limitation, airport planning and management, regulatory compliance, typical flight planning, specialized flight planning (e.g., special departure procedures), flight operations engineering (e.g., aircraft performance), and enroute emergency planning. Most if not all of the information available in the database(s) may be cloud-based, such that the information may be conveniently accessed by other system products/components or functionality via web browser applications on desktop or mobile devices.

[0019] By providing a centralized database(s) of information relating to virtually all aspects of the aviation industry, information access and information sharing are greatly improved - which helps to ensure that all parties are working with common information. Similarly, by capturing and saving changes to information in the database(s) - often in real time - and encouraging and facilitating the uploading of changes to information and/or comments or other feedback (a.k.a. crowd-sourcing) regarding information or perceived inaccuracies in information, it can also be ensured that all parties are working with the most current information available.

[0020] Some exemplary system and method embodiments may be provided as a suite of separate but cooperating and/or interactive components. For example, and for non-limiting purposes of illustration only, an exemplary solution may include one or more of a terminal/airport-based management component, a dynamic charting component, a risk-based performance calculation component, an enroute emergency planning component, and a regulatory compliance component. Access to a given component may be controlled, for example, via license - such that license level or licensing of a particular component(s) determining what services are available to a given user.

[0021] Other exemplary system and method embodiments may be provided as a single product solution that includes all the functionality of an alternative suite of individual components. In such an embodiment, the particular functionality/services available to a given user may be determined, for example, by subscription level.

[0022] Whether embodied as a multi-product suite or a single product solution, it is contemplated that database information will be fully available, and that the products of a suite or the functional aspects of a standalone solution may interact to provide each other with information required to complete a given task. For example, and without limitation, a terminal/airport-based management component may provide obstacle information to a performance calculation component so that the performance calculation component can most accurately calculate various risk-based departure procedures for a given aircraft of interest. Obviously, a multitude of other interactions are also possible.

[0023] Exemplary system and method embodiments described herein may include a common database populated with a multitude of aeronautical and geospatial information that may be easily and conveniently retrieved, and to which like or similar information or changes to information may be easily and conveniently deposited, preferably through the use of a web browser-based application.

[0024] Exemplary embodiments described herein may include novel systems and methods of using aeronautical/geospatial information to manage the risks at and around airports.

[0025] Exemplary system and method embodiments described herein may include a visual interface for managing data quality, procedure, design and risk associated with airports and the areas surrounding airports.

[0026] Exemplary system and method embodiments described herein may facilitate the resolution of conflicts between information from different sources regarding the same subject matter (e.g., the precise geographic/geospatial location of a given obstacle, a runway location, some other object or subject of interest, or attributes of aforementioned and other objects) at or near an airport.

[0027] Exemplary system and method embodiments described herein may utilize convergence of evidence techniques for resolving conflicts between information from different sources regarding the same subject matter.

[0028] Exemplary system and method embodiments described herein may include a modeling method for producing unique, three dimensional aviation virtual surfaces that account for areas within a flight path around an airport for which obstacle data is missing, incomplete or otherwise in doubt. [0029] Exemplary system and method embodiments described herein may include a visual technique for indicating how a selected flight path will penetrate a calculated/generated aviation virtual surface.

[0030] Exemplary system and method embodiments described herein may include a modeling method to determine and apply the effects of the age of an aeronautical survey, or aviation virtual surface, onto the source elevation.

[0031] Exemplary system and method embodiments described herein may visually present the results of risk-based decision making to a user.

[0032] Exemplary system and method embodiments described herein may include risk-based performance data computation functionality that is adapted to calculate a risk score in consideration of takeoff and landing performance, and to present (numerically and/or visually) the risks associated with a given procedure, with performance, or with weight and balance decisions.

[0033] Exemplary system and method embodiments described herein may include risk-based performance data computation functionality that is designed to provide procedure based performance calculations rather than performance calculations based on runway analysis.

[0034] Exemplary system and method embodiments described herein may include risk-based performance data computation functionality that is designed to make aircraft performance information more visual and less mathematical.

[0035] Exemplary system and method embodiments described herein may include risk-based performance data computation functionality that is adapted to conduct complex flight path analyses for aircraft that do not have available 1 ^st principles information.

[0036] Exemplary system and method embodiments described herein may include risk-based performance data computation functionality that is adapted to construct and present sectored aircraft departure procedures directed to one or more engine inoperative or other emergency departure situations, the procedures including one or more possible flight paths depending on the sector of an airport bounding area within which the aircraft is located.

[0037] Exemplary system and method embodiments described herein may include dynamic aeronautical charting functionality that is compatible with modern web browsers, mobile devices and onboard aircraft displays. [0038] Exemplary system and method embodiments described herein may include dynamic aeronautical charting functionality that is capable of dynamically presenting flight procedures, predicted aircraft locations and terminal area information, with real time reaction to changes in information.

[0039] Exemplary system and method embodiments described herein may include dynamic aeronautical charting functionality that permits a user to explore and rearrange the view of aeronautical data that was used to create a given procedure.

[0040] Exemplary system and method embodiments described herein may include dynamic aeronautical charting functionality with improved information presentation capabilities with respect to an aircraft flight path, including integration for previously accepted or selected engine failure procedures.

[0041] Exemplary system and method embodiments described herein may include dynamic aeronautical charting functionality that is adapted to utilize contextually sensitive charts as the same basis for the solution to a given inquiry, regardless of the particular aviation industry sector or personnel type from which the inquiry emanates.

[0042] Exemplary system and method embodiments described herein may include dynamic aeronautical charting functionality that is adapted to visually present an interactive, four dimensional predictive aircraft flight path, based on normal and non-normal operating configurations.

[0043] Exemplary system and method embodiments described herein may include dynamic aeronautical charting functionality that is adapted to display to a user temporary aeronautical data changes in a pre-rendered view of flight procedure or airport/runway information.

[0044] Exemplary system and method embodiments described herein may include dynamic aeronautical charting functionality that is adapted to automatically highlight a graphical depiction of flight procedure information when a user highlights corresponding flight procedure information presented in textual form.

[0045] Exemplary system and method embodiments described herein may include airborne emergency decision-making functionality that provides visual feedback regarding the safest paths to take when experiencing an enroute emergency situation that requires extended navigation over terrain, over water, or over areas in which suitable airports are unavailable for landing.

[0046] Exemplary system and method embodiments described herein may include airborne emergency decision-making functionality wherein sectored potential descent paths are calculated based on common navigational points over terrain, or based on a regional positioning system.

[0047] Exemplary system and method embodiments described herein may include airborne emergency decision-making functionality that is adapted to visually indicate special missed approach procedures for a given airport.

[0048] Exemplary system and method embodiments described herein may include airborne emergency decision-making functionality that utilizes the same aeronautical and geospatial data as other system components or aspects, so as to provide for common user selectable terrain and obstacle considerations.

[0049] Exemplary system and method embodiments described herein may include aviation regulatory compliance and performance impact analysis functionality.

[0050] Exemplary system and method embodiments described herein may include visually-based aviation regulatory compliance and performance impact analysis functionality.

[0051] Exemplary system and method embodiments described herein may include visually-based regulatory compliance and performance impact analysis functionality that is adapted to collect, visualize, and associate collections of, textual information, data tables, business processes, regulations, manuals, guidance materials and other sources of an electronic nature, and to permit access thereto via web browsers and mobile devices.

[0052] Other aspects and features of the invention will become apparent to those skilled in the art upon review of the following detailed description of exemplary embodiments along with the accompanying drawing figures. BRIEF DESCRIPTION OF THE DRAWINGS

[0053] In the following descriptions of the drawings and exemplary embodiments, like reference numerals across the several views refer to identical or equivalent features, and: [0054] FIG. 1 schematically represents a high level view of possible web services architecture for an exemplary system embodiment;

[0055] FIG. 2 schematically represents the interface function of an aeronautical data package that is useable with exemplary system and method embodiments;

[0056] FIG. 3 depicts an exemplary landing page of a terminal area and airport management product of one exemplary system embodiment;

[0057] FIG. 4 depicts an exemplary work area view associated with the exemplary terminal area and airport management product of FIG. 3;

[0058] FIG. 5 depicts an exemplary airport view associated with the exemplary terminal area and airport management product of FIG. 3;

[0059] FIG. 6 represents one exemplary convergence of evidence and de- confliction function associated with the exemplary terminal area and airport management product of FIG. 3;

[0060] FIGS. 7A-7B represent another exemplary convergence of evidence and de-confliction function associated with the exemplary terminal area and airport management product of FIG. 3;

[0061] FIG. 8A schematically depicts a mapped area surrounding an exemplary airport runway, with an indicated area of missing obstacle data;

[0062] FIG. 8B schematically represents the effects of obstacle shadowing and survey age, along with a diminishing risk of obstacle interference with increasing aircraft altitude;

[0063] FIG. 9 schematically depicts a multitude of obstacles along a given flight path within some bounding area around the runways of an exemplary airport, wherein the obstacles are represented as cylinders whose height represents the obstacle elevation;

[0064] FIG. 10 depicts a terrain-based spline fitted aviation virtual surface (AVS) applied over the bounding area and obstacle features of FIG. 9;

[0065] FIG. 1 1 depicts the spline fitted AVS of FIG. 10 in conjunction with a rasterized set of FAA Part 77 protection surfaces;

[0066] FIG. 12 represents an alternative visual presentation (i.e., a profile view) of flight path risk based on an AVS determination; [0067] FIG. 13 represents the general use of a calculated AVS as part of a risk-enabled and performance-based procedure modeling and design function;

[0068] FIG. 14 depicts an exemplary page of an aircraft performance calculation product/function of one exemplary system embodiment;

[0069] FIG. 15 represents an exemplary visual presentation of various possible departure paths with associated risk scores as calculated and presented by the aircraft performance calculation product/function represented in FIG. 12;

[0070] FIG. 16 represents an exemplary numerical chart/table that can be generated by an exemplary aircraft performance calculation product/function and used to produce a selected departure risk under alternative weather and aircraft performance conditions;

[0071] FIG. 17 depicts one exemplary route special departure procedure (RSDP) chart that is producible by an exemplary system embodiment;

[0072] FIG. 18 depicts another exemplary RSDP chart that is producible by an exemplary system embodiment;

[0073] FIG. 19 depicts yet another exemplary RSDP chart that is producible by an exemplary system embodiment;

[0074] FIG. 20 is a 3-dimensional representation of an exemplary sector special departure procedure (SSDP);

[0075] FIG. 21 generally represents the various elements of an exemplary SSDP;

[0076] FIGS. 22A-22B are enlarged views of an exemplary SSDP diagram comparing a SSDP having only an initial straight area (ISA) with a SSDP having an ISA and an ISA extension;

[0077] FIG. 23 schematically illustrates the concept of SSDP navigational aid (NAVAID) restriction area intersections;

[0078] FIGS. 24A-24C demonstrate various exemplary SSDP flight paths from an ISA or ISA extension end line to an obstacle, along with derived obstacle heights relevant to the flight paths;

[0079] FIG. 25 illustrates potential SSDP flight path construction problems associated with an obstacle located near an ISA or ISA extension end line;

[0080] FIG. 26 illustrate exemplary SSDP flight paths for a sector; [0081] FIG. 27 illustrates potential SSDP flight path construction problems associated with an obstacle located near an ISA or ISA extension lateral boundary line;

[0082] FIG. 28 depicts several possible exemplary flight paths to an obstacle;

[0083] FIGS. 29A-29E represent an exemplary obstacle filtering process for use in SSDP construction;

[0084] FIG. 30 depicts one exemplary SSDP chart that is producible by an exemplary system embodiment;

[0085] FIG. 31 depicts another exemplary SSDP chart that is producible by an exemplary system embodiment;

[0086] FIG. 32 is a non-exhaustive collection of unique symbols that may be used on special departure procedure (SDP) charts producible by exemplary system and method embodiments;

[0087] FIG. 33A illustrates how various layers of a chart, such as the SSDP chart of FIG. 31 , may be turned on or off according to at least some exemplary system and method embodiments;

[0088] FIG. 33B represents the SSDP chart of FIG. 31 with certain layers turned off according to FIG. 32A;

[0089] FIG. 34 is an exemplary SID chart that may be generated by exemplary system and method embodiments;

[0090] FIG. 35 is an exemplary instrument approach chart that may be generated by exemplary system and method embodiments;

[0091] FIG. 36 is another exemplary instrument approach chart that may be generated by exemplary system and method embodiments;

[0092] FIG. 37 is an exemplary enhanced SID chart showing both an all engines operative and a one engine inoperative flight path;

[0093] FIGS. 38-39 illustrate exemplary dynamic aeronautical charting functionality of an exemplary system and method embodiment, wherein textual or graphical flight procedure information is automatically highlighted when a user selects the corresponding flight procedure information presented in opposite form; [0094] FIG. 40 is a portion of an exemplary SID chart that demonstrates the predictive flight path modeling and charting abilities of an exemplary system and method embodiment;

[0095] FIG. 41 is an exemplary visual presentation of data relating to the airborne emergency decision-making functionality present in an exemplary system embodiment; and

[0096] FIG. 42 is a diagrammatic functional representation of one exemplary visual interface to regulatory compliance and performance impact analysis aspect of an exemplary system embodiment.

[0097] It should be noted that the drawings provided herein are not necessarily drawn to scale, and certain portions of said drawings may be enlarged or otherwise enhanced for purposes of illustration. For example, and without limitation, the initial straight area and/or central disc area of the special sector departure procedure diagrams and charts appearing in the drawing figures may appear disproportionately large.

DETAILED DESCRIPTION OF THE EXEMPLARY EMBODIMENTS

Architecture

[0098] As described above, exemplary system and method embodiments will typically have an aeronautical/geospatial database, or series of databases. For non-limiting purposes related only to illustration and identification within this application, this database or collection of databases, will be referred to as the TEAMDB. The TEAMDB may contain information regarding, for example, airports, runways, aircraft performance data, aeronautical features, navigational aids, communication infrastructure, earth data such as terrain and other features, land use, and land cover, obstacle data, regulatory information, etc. Generally speaking, the TEAMDB may contain all the information required to effectuate any feature or perform any function of any exemplary system and method embodiment described herein. The TEAMDB may be cloud-based, such that the information available therein may be conveniently accessed by other system components or functionality via a web browser and mobile applications. At least some TEAMDB data may be retrieved and stored locally on mobile and other devices to permit certain functionality in the absence of an Internet connection. [0099] A schematically-represented high level view of exemplary web services architecture that incorporates the TEAMDB is presented in FIG. 1 . Such an architecture may be employed by an exemplary system, or component of a system, described herein.

[00100] As shown in FIG. 1 , the TEAMDB is in communication with the Internet (Web) through an intermediary extract/transform/load component (ETL) that generally speaking, ingests aviation-related data from a multitude of authoritative sources (data bases, files, web services, etc.) and automatically and semi- automatically populates the TEAMDB. The ETL may also receive data from, for example, airport and operator sources - which data may also be added to the TEAMDB once appropriately vetted and quality assured. One or more customer databases may also exist separately from the TEAMDB. Such customer databases may contain private information that a given customer does not want to share with other industry users. For example, a customer database may contain privately contracted survey information, operation standards governing the flight procedures of the customer, etc. Exemplary system embodiments permit isolation of such a customer database to only the owner (or other authorized user) of the database.

[00101 ] As a majority of the functionality of an exemplary system embodiment is intended to be accessible via an Internet-connected web browser, the TEAMDB and optional customer database(s) are in communication across a database tier (DB) with corresponding web servers that facilitate communication between an Internet-connected user and the databases. The web servers may be a feature of cloud-computing services offered by, for example, Amazon® Web Services - a design feature that permits exemplary system embodiments to be virtually infinitely scalable to accommodate fluctuation levels of user traffic.

[00102] The left hand side of FIG. 1 particularly represents exemplary architecture associated with an exemplary terminal area and airport management product/function of an exemplary system, wherein the terminal area and airport management product/function has been designated as the T+ web application only for the sake of brevity. It can be observed that the T+ App, which may be implemented as a JavaScript® application, communicates with the web services, and thus the databases, through a product specific service. The product specific service performs orchestration services between the function- specific web services and the T+ web application. In effect, this patter allows for the creation of multiple products using a recombined set of back-end function- specific web services.

[00103] Moving now toward the right of FIG. 1 , the architecture associated with an exemplary aircraft performance calculation product/function of an exemplary system may be observed. As shown in FIG. 1 , the aircraft performance calculation product/function has been designated as the P+ application only for the sake of brevity. The P+ application receives data from the databases across a computational and business tier (CO) BT, via associated web services, with orchestration services again performed by an appropriate product specific service.

[00104] As also represented in FIG. 1 , the P+ application may be provided with information generated by one or more performance modules Pi - P3 that reside on a separate and scalable server that is in communication with the web services. The performance modules may, for example, perform various aircraft performance calculations as requested via the P+ application. Data from the performance module server may also be provided to a separate application running on a mobile device.

[00105] As indicated in FIG. 1 , other products/components (e.g., XYZ applications) would communicate with the TEAMDB and possibly a customer database(s) in a similar manner according to the illustrated and exemplary architecture. Variations to the architecture are, of course, possible depending on the nature of a given XYZ application.

[00106] FIG. 2 schematically represents the interaction between the TEAMDB and a specially developed aeronautical data package (data package) which, generally speaking, is comprised of a set of data files that are written to the file system for input by an automated charting and encoding (ACE) engine and a global procedure designer (GPD). The ACE engine is responsible for generating aeronautical charts, such as but not limited to, the novel special departure procedure (SDP) charts that are described in more detail below. Among other things, the GPD may be responsible for producing airport, runway and NAVAID surfaces, and for designing route SDP and sector SDP charts. [00107] The data package may include, for example, aeronautical and procedure data. The data package acts as an interface mechanism that, among other things, isolates the ACE engine and the GPD from the TEAMDB, thereby leveraging the capability in TEAMDB to generate a data set in the National Geospatial Intelligence Agency's (NGA's) digital aeronautical flight information file (DAFIF) and digital vertical obstructions file (DVOF) formats. The data package may utilizes the base NGA specification but modifies and extends the specification to meet increased functionality demands.

Terminal and Airport

[00108] Referring now to FIGS. 3-5, various exemplary web pages of an exemplary terminal area and airport management product/function may be observed. For purposes of only illustration and identification, the terminal area and airport management product/function is labeled as Terminal + in FIGS. 3-5 (see also T+ in FIG. 1 ). As shown, this exemplary landing page allows a user to select from a number of options, including searching for a particular airport by International Civil Aviation Organization (ICAO) designation or by a TEAMDB designation or identification (ID), as well as performing an aeronautical data search, accessing a customer profile, or creating an entity (profile). Other landing page designs, layouts and options are, of course, possible, and nothing presented in FIG. 3 is to be interpreted as limiting the appearance or content of such a landing page.

[00109] Upon selection of an airport, various other pages and options may be presented. FIG. 4 represents an exemplary additional page that may be presented following airport selection. In this case, FIG. 4 visually depicts an exemplary work area view that includes the selected airport, as well as other airports that are within some predefined or user selectable geographic area surrounding the selected airport. An abundance of additional information may be provided on such a graphic presentation, including but not limited to depicted airport boundaries, runways, the presence of navigational aids and waypoints, obstacles, and flight path information. Such information may be represented by various icons, as indicated along the upper-left side of the page in FIG. 4.

[00110] In this particular Terminal + product/function example, layer manipulation is also permitted and provided for. For example, each type of information shown may be associated with a given layer of the presented graphic, such that a user can selectively allow or suppress the appearance of a given type of information(s).

[00111 ] FIG. 5 represents another exemplary page that may be presented following airport selection via the landing page of FIG. 3. In this case, FIG. 5 visually depicts a more detailed view of the selected airport and the area immediately surrounding the selected airport. This view also presents a better indication of obstacles in the potential flight path of an approaching or departing aircraft. Specific airport information is also provided, such as but not limited to the airport ICAO code designation (KEGE in this example), the airport name, and the airport type. A variety of other airport information may also be presented.

[00112] The exemplary page of FIG. 5 also specifies to a user the data sources from which the information used to generate and locate the indicated runways, airports, obstacles, etc., was retrieved, or from the sources from which the information is optionally retrievable. For example, it is indicated in this example that available host nation data sources for the selected airport include FAA CIFP (A424-18) and FAA NFDC. It is also indicated that the information currently displayed is derived from the FAA NFDC data source. It is further indicated that other non-host nation (customer) data sources are also available.

[00113] As should be obvious, a terminal area and airport management product/function such as the exemplary T+ product/function described above and illustrated in part in FIGS. 3-5, is useful to a multitude of different users for a variety of different purposes. Relevant users include, but are not limited to, airport operators, airport designers/builders, airport regulators, pilots, dispatchers, engineers and other personnel associated with flight planning or flight management, manufacturers of aircraft and navigational equipment, and even flight simulator manufacturers. For example, an airport operator might use an exemplary version of the T+ product/function rather than a traditional notice to airmen (NOTAM) or other mechanism to upload airport changes for viewing by airlines and others that utilize the affected airport. An exemplary T+ product/function may permit the airport operator to easily include a description of how the airport changes will affect flights into and out of the airport. Such a notification would become viewable to all users of the associated system as soon as uploaded by the airport operator.

[00114] Airport designers/planners might use an exemplary T+ product/function to, for example, generate runway mockups or to create a hypothetical asset, and the data associated with such activities may be exported to one or more other products/functions of the associated exemplary system to determine the sufficiency of the design or the effect of the construction. As described in more detail below, designers/planners may also use related protection surface (e.g., aviation virtual surface) data to see how a given airport is affected. Airport regulators might use an exemplary T+ product/function to, for example, test risk concepts, develop planning surfaces, etc. Users such as pilots, dispatchers and engineers might use an exemplary T+ product/function to, for example, see airport information or changes to airport information input by airport operators or others, so that said users have the most current and accurate data against which to fly. Users such as pilots, dispatchers and engineers might also compare the output of information available from an exemplary T+ product/function to a different source of related information, such as an existing chart or NOTAM, to note and possibly resolve any conflicts.

De-confliction

[00115] As would be well understood by one of skill in the art, conflicts between information from different data sources regarding the same information often exist. Common conflicts might include, for example and without limitation, the starting point, length, elevation and/or precise orientation of a particular runway at a given airport, or the presence, location and/or elevation of obstacles within some flight path of interest. Conflicting information can be dangerous - particularly when the source of information ultimately relied upon is wrong. Therefore, another possible feature of an exemplary system and method of the present application is the ability to consider airport and obstacle data from multiple sources, and to perform a de-confliction operation on said data so as to visually present a user with best available information relating to an airport and/or associated area of interest. Such functionality may be an aspect of a terminal area and airport management product/function of an exemplary system embodiment. However, exemplary systems embodiments are not so limited, and such functionality may instead be provided by another product/function.

[00116] FIG. 6 schematically represents one example of the aggregation and de-confliction of information described generally above. In this example, a user has selected a particular airport of interest, and the user desires to see the location and elevation of obstacles surrounding the airport. As may be observed from the first image in FIG. 6, the obstacle data obtained from the FAA No. 405 Spec for this particular airport is insufficient with respect to both the currency and coverage. As a result, this exemplary system also considers Airports Geographic Information Systems (AGIS) obstacle data and applies the AGIS-identified obstacles to the chart, as indicated by the second image of FIG. 6. The exemplary system next performs a de-confliction operation between the FAA No. 405 Spec and AGIS obstacle data to obtain and present an optimized obstacle chart, which is represented by the third image of FIG. 6.

[00117] Exemplary system and method embodiments may permit comments and/or other feedback from relevant users (e.g., airport personnel, airline operators, pilots, etc.) regarding the location, elevation and/or other characteristics of obstacles, and may store such information in the TEAMDB or elsewhere for subsequent retrieval and use by one or more products/functions of the system. Consequently, the exemplary system of FIG. 6 also considers and uses such information when determining and presenting the number, location and elevation of obstacles to the user. The inclusion and presentation of user-supplied obstacle data is represented in the last chart image of FIG. 6, where the user-supplied obstacle data has been added to the de-conflicted obstacle data described above to provide the user with the best available indication of obstacle presence, location and elevation.

[00118] While data aggregation and de-confliction can be used to produce a best available solution, as represented in FIG. 6, a best available solution is not necessarily the most accurate or optimized solution. With this in mind, exemplary system and method embodiments described herein may include the ability to determine a best obtainable solution whose accuracy exceeds that of a best available solution. [00119] One example of providing a best obtainable versus a best available solution to a query is schematically represented in FIGS. 7A-7B. In this particular example, the best obtainable solution is the most likely geospatial location and orientation of a runway of interest, but the described functionality may be applied equally well to other subject matter for which there is a conflict between data sources.

[00120] FIG. 7 A represents an overlay of runway location and orientation according to three different data sources. The runway data may be obtained from, for example, host nation data, survey data, imagery data, etc. A different number and/or type of data sources may be considered in other embodiments. In any case, as may be observed in this example, the precise geospatial location and orientation of the runway is slightly different according to each data source. Thus, if the data sources used to indicate the runway location and orientation in this example were considered to be the best available sources, a user would be left to guess as to which of the indicated locations and orientations is correct.

[00121 ] Alternatively, an exemplary system embodiment may determine and present a best obtainable estimate of the true location and orientation of the runway of interest. Such a best obtainable location is shown in FIG. 7B. In this example, the best obtainable runway location and orientation does not coincide precisely with any of the overlaid locations and orientations depicted in FIG. 7A (although such may not always be the case). Rather, the best obtainable runway location and orientation presented in FIG. 7B is the result of the exemplary system applying a convergence of the evidence technique to the available runway data, and applying a mathematical algorithm to said data to best estimate the true location and orientation of the subject runway. The algorithm may consider various factors such as, but not limited to, the general accuracy associated with the technique from which a given data set was produced (e.g., a ground-based survey versus satellite imagery, etc.).

[00122] A user of an exemplary system wherein best obtainable solution functionality is offered, is not required to make use of said functionality. For example, in the case of the runway of FIGS. 7A-7B, a user may prefer to go with their own best guess as to true runaway location and orientation rather than a system-calculated estimation thereof. As with the aggregation and de-confliction functionality illustrated in FIG. 6, best obtainable solution functionality of an exemplary system may be associated with a terminal area and airport management product/function of an exemplary system embodiment, or with another product/function of the exemplary system.

Aviation Virtual Surfaces

[00123] As described above, airport area and obstacle data may be used in a variety of ways. However, exemplary systems and methods described herein may also novelly employ obstacle data to produce a heretofore non-existent aviation virtual surface (AVS) around a given airport.

[00124] It is not uncommon for a given area around an airport that may be relevant to a desired flight path to be indicated on charts as being devoid of or substantially devoid of obstacle data, whether due to a lack of survey or other mapping information, due to shadowing, or otherwise. Such an area is represented as the devoid area within the dashed circle of FIG. 8A. While such an area may appear to be devoid of obstacles for such reasons, experienced aviation personnel understand that the risk of obstacles nonetheless existing in such an area (see FIG. 8B) must be taken into consideration for purposes of, for example, airport planning/design, flight procedure design/development, and aircraft performance calculations and risk management. However, there is currently no known system or method for accurately predicting the location and elevation of obstacles in such an area nor, therefore, is there currently a known system or method that permits an interested party to assess the risk of a desired flight path over such an area.

[00125] Exemplary system embodiments may, therefore, determine and associate an AVS with an area having inadequate obstacle data. With respect to the present application, an AVS may be thought of generally as an obstacle and terrain probability surface that is calculated and visually presented to indicate the risk that a vertically-oriented obstacle exists at a given geographic location within an area that is devoid or substantially devoid of obstacle data.

[00126] More specifically, the AVS functionality is operative to create a series of three dimensional surfaces whose geospatial parameters may be derived from independent sources of elevation information. Disparate sources of elevation, terrain, manmade obstructions, land use, land cover, survey identification surfaces, airspace protection surfaces, runway protection surfaces, NAVAID protection surfaces and existing flight procedure/airspace surfaces/volumes are combined into multiple raster/vector surfaces that represent confidence intervals related to the certainty of a user about the elevation of the surface of the earth plus natural and man-made obstructions (expressed as vertical likelihood). Users of a system with AVS generation functionality will therefore be able to model geometric lines, polylines, polygons, rasters and other complex geometries that can either penetrate one or multiple layers of an AVS or remain above one or more layers of the AVS, depending on the use case. If a user elects to penetrate an AVS via a desired flight path, for example, the portion of the path that penetrates the AVS will be exposed to a "risk" or "likelihood" of contacting vertical features of the earth or other vertically-oriented (e.g., manmade) obstacles.

[00127] The creation of an AVS is a complex process comprised of a number of different steps. Broadly described, however, an AVS is created according to one exemplary system embodiment by first establishing a model of the earth's surface. This step may actually involve establishing a plurality of "earth surfaces", such as but not limited to a primary earth surface, a secondary earth surface, a first tertiary earth surface, and a second tertiary earth surface. Each of these surfaces is established based on surface data from a specific data source or upon the aggregation of surface data from particular combinations of data sources. In the event of a data conflict, a de-confliction operation may be employed.

[00128] Once the earth surfaces are established, the next step in this exemplary AVS generation process is improving the earth surface model. Generally speaking, this means introducing survey areas with better resolution or improved accuracy or currency, introducing new land cover raster or vector information, introducing land use data, and or utilizing other similar enhancement techniques.

[00129] Subsequent to the step of improving the earth surface model, this exemplary AVS generation process then moves to establishing obstacle surfaces. Establishing obstacle surfaces may be a multi-step process. For example, initial establishment of obstacle surfaces may involve locating all obstacles in an area within some radius around an airport of interest; establishing point obstacle locations according to obstacle nominal X, Y, Z coordinates; establishing vector boundaries between any point obstacles identified as being "connected" obstacles; determining the survey types and dates from all obstacles detected; and retaining survey surfaces and obstruction points, polylines and/or polygons as viewable layers. If a user creating an AVS believes that multiple obstacles (from different data sources) are all representations of the same thing, then a de-confliction operation may be undertaken. The establishment of obstacle surfaces may then proceed to establishing multiple obstacle surfaces, such as but not limited to, a primary obstacle surface, a secondary obstacle surface, a first tertiary obstacle surface and a second tertiary obstacle surface.

[00130] Subsequent to the establishment of obstacle surfaces, this exemplary AVS generation process may then move to the step of defining protection surfaces. The protection surfaces to be defined may include, for example and without limitation, runway protection surfaces, airspace protection, airport protection, NAVAID protection, lighting protection, flight path protection, and all protection surfaces. In this example, it may next be determined what portion of the calculated probability surfaces (volumes) are within Federal Aviation Regulation (FAR) Part 77 (obstructions to navigation) or ICAO Annex 14 surfaces, and what portion is not.

[00131 ] The aforementioned AVS data sources and AVS generation steps are used to produce a graphical (i.e., visually-presentable) aviation virtual surface for a given area around a selected airport. The process and a resulting exemplary AVS are represented generally by FIGS. 9-1 1 . A multitude of detected vertically extending obstacles in the form of earth surfaces and/or other obstacles within an area supposedly devoid of such features, are represented in FIG. 9 by a like number of vertically-oriented cylinders. The position of each cylinder coincides with the geographic location of a corresponding detected feature, while the height of a given cylinder represents the elevation of its corresponding feature.

[00132] An AVS may be visually presented as, for example, a spline tension surface - meaning a surface that is produced through spatial interpolation by fitting tension splines between input points (i.e., determined obstacles). As represented in the example of FIG. 10, such a surface may be visualized generally as a sheet of flexible material that is draped over a series of underlying objects of different elevations. In the case of FIG. 10, the underlying objects of different elevations are the cylinders of FIG. 9 that represent a multitude of detected vertically extending obstacles. The three dimensional nature of the generated surface as well as areas of greatest and lowest elevation are clearly evident on the AVS of FIG. 10. As indicated, an AVS may also utilize color to indicate elevation (i.e., be presented as a "heat map"), such as in FIG. 10, where the reddish tones represent lower elevations, and yellows and greens represent higher elevations. When color is used, a color scale may also be provided to associate a particular color with a corresponding elevation.

[00133] When the number of input points is low and/or the variation in elevation between input points is small, an AVS may appear less contoured. An AVS with minimal contour variation may be representative of a surface created, for example, using only basic terrain data, or possibly a surface generated using a regularized spline, as opposed to a tension spline, fitting method.

[00134] In FIG. 1 1 , a rasterized set of FAR Part 77 protection surfaces (as represented by the blue and purple hues) associated with the area in question has been combined with the AVS of FIG. 10. As can be observed, the area of interaction between the FAR Part 77 protection surfaces and the AVS results in a further enhanced graphical representation of the area surrounding the exemplary airport and, thus, an even better understanding of the overall surface against which takeoffs and landings must be executed.

[00135] The results of an AVS calculation may also be presented to a user in other ways. For example, instead of or in addition to surface like that presented in FIG. 1 1 , the results of an AVS determination may be presented in a manner like or similar to that illustrated in FIG. 12. In FIG. 12, a number of exemplary obstacles in the form of vegetation, a radio tower and a building are shown to reside in an area surrounding an airport that is generally indicated as being devoid of obstacles based on one or more typical sources of available information. However, after employing an AVS generation technique such as that described above, it is determined that obstacles exist and an AVS is developed and applied to the area of interest. As the obstacles may interfere with a departing aircraft, the AVS can be used to visually indicate the percentage of risk of not clearing one or more of the obstacles on takeoff for various flight paths having different performance characteristics. In this particular example, the performance characteristics of each flight path is indicated as a height above the runway at a given distance from brake release (i.e., a climb rate). Each flight path is also designated as having a particular percentage of risk.

[00136] It can be understood from FIG. 12 that AVS generation functionality may be a feature of a risk-enabled and performance-based procedure modeling and design technique. For example, once an AVS is generated, the AVS may be used along with other information to determine risk-based flight procedures. Such a risk-enabled and performance-based procedure modeling and design technique may also require the functionality and/or data associated with more than one product/function of an exemplary system embodiment. For example, such a modeling and design technique may incorporate planning, regulatory compliance, performance calculations, and charting functionality. The basic concept of using an AVS in risk-enabled and performance-based procedure modeling and design is represented generally in FIG. 13.

Aircraft Performance

[00137] As previously mentioned, exemplary system and method embodiments may include aircraft performance calculation functionality. The aircraft performance calculation functionality is intended to provide a risk-based performance data computation platform that allows the associated exemplary system to calculate limiting takeoff and landing performance, and to present a user with the numerical and visual risks associated with the performance calculation process, flight procedure design, and weight and balance assumptions. In the context of flight operations, this allows a user to understand the risks associated with a given procedure, with performance, or with weight and balance decisions - in other words, to balance risk and return. Such a method of flight procedure design differs from typical methods in that it employs procedure-based performance calculations as opposed to those based on, for example, a runway analysis.

[00138] In this regard, FIG. 14 illustrates an exemplary data entry page of an exemplary performance calculation product/function of such a system. As shown in FIG. 14, a user may select a particular aircraft for which to undertake a performance calculation. The system facilitates the input of various other information for use in the performance calculation. For example, and without limitation, performance may be calculated with respect to a given airport and a particular runway at said given airport. The condition (e.g., wet/dry) of the runway may also be input, as may, without limitation, other airport/runway characteristics such as elevation, slope and runway length information (e.g., TORA, TODA, ASDA); aircraft conditions such as but not limited to weight, anti- ice and flap settings; and environmental conditions such as wind speed and direction, barometric pressure and temperature. METAR data may be provided as shown to assist a user with providing the required environmental input data.

[00139] Based on the input data, the exemplary performance calculation product/function then calculates a risk score in consideration of performance (i.e., most risky vs. most likely). Calculated risk scores in consideration of performance may be visually presented to a user in several ways. One example of such a visual presentation appears in FIG. 15. In the exemplary presentation of FIG. 15, several calculated possible departure flight paths are presented for a given aircraft, airport, runway, weather conditions, etc., as explained above. For purposes of illustration, risk scores are associated with some of the possible flight paths. While these exemplary risk scores use a combination of alphanumeric and numeric characters, other formats are of course also possible. The presentation of FIG. 15 also indicates the source(s) of data upon which each calculated flight path is based.

[00140] Upon selecting a flight path from the graphical presentation of FIG. 15, a pilot or other user may be presented with numerical data in the form of a chart or table that will allow the given aircraft to maintain a like risk score with changes in environmental conditions (e.g., barometric pressure and/or temperature) and/or aircraft performance parameters (e.g., takeoff speed). One such exemplary data table is illustrated in FIG. 16, as may be presented to a user on a mobile device such as an iPad®, etc., for convenience and ease of use.

[00141 ] In making performance calculations, a performance calculation product/function of an exemplary system may also use data obtained from sources other than the data entry source illustrated in FIG. 14. For example, a performance calculation product/function of an exemplary system may import relevant data form other products/functions associated with the system. These other products/functions may include, without limitation, a terminal area and airport management product/function and a regulatory compliance product/function. In the former case, imported data may include data related to, for example, an initial straight area (ISA), an ISA extension, a straight segment, and sectors of a geometric bounding area of interest.

Special Departure Procedures

[00142] Another possible feature of an exemplary system embodiment is the ability to create a special departure procedure (SDP). One basic example of such a special departure procedure is a route special departure procedure (RSDP) that provides instructions and guidance for a one engine inoperative departure situation. A RSDP is described as being basic in nature herein because it includes only one route.

[00143] One example of a RSDP producible by an exemplary system and method embodiment is illustrated in FIG. 17. As can be observed, this exemplary RSDP is associated with a departure from Runway 33 of the Aspen/Pitkin County Airport (KASE/ASE) in Aspen, Colorado, and includes instructions and route guidance for returning to KASE upon a one engine inoperative departure situation. A second example of a RSDP producible by an exemplary system and method embodiment is illustrated in FIG. 18. This RSDP is also associated with a departure from Runway 33 of KASE, but is presented in portrait format as opposed to the landscape format of the RSDP of FIG. 17. Additionally, the RSDP of FIG. 18 directs an aircraft to the Rifle Garfield Regional Airport (KRIL) in Rifle, Colorado in the case of a one engine inoperative departure situation.

[00144] An exemplary enhanced version of a RSDP producible by an exemplary system and method embodiment is illustrated in FIG. 19. In comparison to the RSDP charts of FIG. 17 and FIG. 18, the RSDP chart of FIG. 19 includes additional information. For example, the RSDP chart of FIG. 19 includes flight operation instructions that are superimposed along the flight path depicted on the chart for both an engine failure and all engines operating situation. The RSDP chart of FIG. 19 also includes specific flight operation procedures for an all engines operating takeoff, whereas the RSDP charts of FIGS. 17-1 8 simply instruct the user to follow the standard instrument departure (SID) associated with the nearby LINDZ waypoint. A number of unique SDP symbols also appear on the RSDP chart of FIG. 19 to provide additional weather, obstacle and other miscellaneous information to a user. A non-exhaustive collection of such SDP symbols are shown in enlarged form in FIG. 32, along with a brief description of their meaning. These SDP symbols may be used on other types of SDP charts, such as for example, the exemplary SSDP charts described below and shown in FIGS. 30-31 .

Sector Special Departure Procedures

[00145] Another, novel, example of a special departure procedure is a sector special departure procedure (SSDP). Generally speaking, a SSDP takes into account the obstacle and terrain environment surrounding a given airport and presents different possible flight paths for a one or more engine inoperative or other emergency departure situation depending on the given sector of a defined airport bounding area within which the aircraft is located. The determination of a SSDP may also consider various aircraft performance parameters, such as but not limited to, radii of turn corresponding to two selected speed values, nominal climb gradient, critical climb gradient for obstacle reporting, loss of climb gradient in turns, minimal profile used for obstacle filtering, and maximal value of the climb gradient.

[00146] A SSDP algorithm may deploy a simplified aircraft model and may seek the most critical case that results in maximum climb performance degradation. The algorithm may further augment obstacle/terrain altitudes by a value corresponding to the loss of climb gradient along each of the flight paths and may sort all obstacles and terrain points for a sector by the distance along the corresponding flight path. These augmented and sorted obstacles and terrain points may then be pushed through a multi-step filtering process to produce a list of significant obstacles and terrain points in the various sectors.

[00147] FIG. 20 generally and three-dimensionally illustrates the concept of a SSDP for a particular runway 5 of a given airport, showing, among other things, the aforementioned sectored airport bounding area 10; an initial straight area (ISA) 15 at the departure end of the runway; a straight segment 20 extending from the ISA; and several exemplary imaginary flight paths 25 to an exemplary obstacle/terrain point 30 in an exemplary sector 35 as determined by a specialized algorithm that considers significant obstacles and terrain points in the sector which, if cleared, guarantee safety for a one or more engine inoperative takeoff or other emergency departure situation, reaching a declared sector safe altitude.

[00148] In FIG. 20, each of the alternate flight paths 25 shown is composed of an initial turn 40 to a heading that results in a straight path 45 to the obstacle 30. When the aircraft flight path reaches the position of the obstacle 30, the flight path transitions to a climbing turn with a spiral trajectory that allows the aircraft 50 to reach the sector safe altitude. These connected turns may be calculated to create the least favorable flight path, maximizing the loss of climb gradient. The climb gradient loss is then converted to an altitude decrement that is used to compute derived obstacle height and to compare values for different flight paths.

[00149] The concept of SSDP is further illustrated by the diagram of FIG. 21 , wherein a plan view of a sectored bounding area surrounding a given airport is represented. In this example, the airport bounding area 100 is circular in shape. It should be understood, however, that other bounding area shapes may be employed in other examples.

[00150] In the example of FIG. 21 , the airport bounding area 100 is centered over a navigational aid (NAVAID), which in this case is a very-high frequency omnidirectional range (VOR) device in combination with distance measuring equipment (DME). In other embodiments, a SSDP may be based on a different NAVAID(s), such as but not limited to a non-directional beacon (NDB) or a tactical air navigation (TACAN) system. A SSDP may also rely on a global positioning system (GPS). The type of NAVAID at which the SSDP bounding area is centered will depend on the NAVAID(s) present/available at a given airport. It is also possible that a bounding area may be located at an airport reference point (ARP) that is not centered over a NAVAID.

[00151 ] As mentioned above, the SSDP represented by FIG. 21 has an airport bounding area 1 00 that is centered over a combined VOR-DME NAVAID 105. A central bounding area in the form of a central disc area 1 1 0 is also centered at the NAVAID 105 so as to be concentrically located within the airport bounding area 100. The central bounding area may be of other shapes in other embodiments. Broadly speaking, the central disc area 1 10 serves as a transitional area or zone between sectors, which are adjacent the central disc area. The central disc area 1 10 is constructed using projected geometry, and the radius of the disc may be specified as an input parameter during the SSDP construction process.

[00152] SSDP sector partitioning is defined by a list of radials (bearing values) radiating from the bounding area center point (the VOR-DME 105 in this example), such that a sector Si is defined from the central disc 1 10 to the limit of the bounding area 100, between an i-th and i+1 radial, where i=2...n, and with the last sector defined between n-th and the first radial. If no sector radials are specified during SSDP construction, the entire SSDP bounding area 100 may be processed as a single area. In addition to the bearing-based definition described above, sector radials can also be defined using a second (latitude, longitude) point non-collocated with the bounding area center point 105. The true bearing of a sector boundary may then be computed using an inverse solver for a geodetic line.

[00153] As shown in FIG. 21 , the bounding area 100 for this exemplary SSDP is divided into four sectors - Sector 1 , Sector 2, Sector 3, and Sector 4. The circular nature of the exemplary bounding area 100 in this example results in the sectors being generally pie-shaped. Each of the four sectors in this example is also labeled with a respective sector safe altitude of 1 ,500 feet, 1 ,700 feet, 4,000 feet and 3,000 feet, as determined by the SSDP algorithm described above in view of known obstacles/terrain points (hereinafter collectively obstacles for brevity) present in each sector. The sector safe altitudes represent the altitudes at which all obstacles within a given sector will be cleared. The types and elevations of various obstacles may be indicated in some or all of the sectors, such as through the use of known symbols as shown.

[00154] As in FIG. 20, the SSDP diagram of FIG. 21 presents a runway of interest 120 which, in this case, lies substantially within Sector 1 . The runway 120 is also shown as being encompassed within the central disc area 1 1 0 (although the central disc area is not drawn to scale in FIG. 21 ). The SSDP represented in FIG. 21 is directed to an emergency situation departure from the runway 120, such as but not limited to a one or more engine inoperative departure.

[00155] An initial straight area (ISA) 125 is also depicted in FIG. 21 . The ISA 125 begins at the departure end of the runway 120 and has a generally trapezoidal shape. The centerline of the ISA 125 is preferably aligned with the centerline of the runway 120, but some degree of misalignment may be permissible.

[00156] The termination point of the ISA 125 may be specified as an input parameter during the SSDP construction process based on the relied upon NAVAID/navigation method, on obstacles outbound of the runway 120, and on performance and other characteristics of a given aircraft. The end of the ISA 125 may be defined by a limiting radial, a geodetic arc (a limiting DME measurement) centered at the center of the airport bounding area, a distance measured along an ISA bearing line, etc.

[00157] Generally speaking, the end of an ISA should typically serve as a convenient and safe point at which a given aircraft may initiate a path to other sectors, and also as a starting point for a subsequent straight segment (see below) within which the aircraft would be assured of having lateral maneuvering capability. Thus, an ISA preferably can be well-defined by the relied upon navigation method, and has a termination point that is sufficiently far away from the runway end to set up a useful straight segment but not so far away from the runway end that the aircraft must be flown on the runway heading for an excessive period of time. In other words, a well-designed ISA in conjunction with well-designed sectors, should enable the pilot of an aircraft to quickly, using their own performance-based flight path determination, turn around to setup on the downwind leg of the airport, and then land on the same runway in the same direction from which the aircraft originally took off. An ISA is not, however, always so definable.

[00158] As can be understood by additional reference to FIGS. 22A-22B, alternate methods of ISA construction/definition may be employed. In the embodiment represented by FIG. 22A (and as is shown in FIG. 21 ), the point of ISA termination is the point at which the turn geometry 130 of the aircraft of interest is contained with the lateral boundaries of the ISA 125. In other words, the termination point of the ISA 125 is the point at which the aircraft of interest, flying along one lateral boundary of the ISA, can make a 1 80 degree turn and remain within the ISA. Such an ISA comports well with the aforementioned desired characteristics.

[00159] It may not, however, always be possible to terminate an ISA at the point where the turn geometry of the aircraft of interest is contained within the lateral boundaries of the ISA while still maintaining the ISA termination point within a desirable distance from the end of the runway. For example, in the case of a very large aircraft with a large turning radius, defining the termination point of the ISA as the point where the aircraft is able to turn around while still remaining within the ISA could place the ISA termination point so far from the end of the runway as to diminish or even render pointless the other sectors of the SSDP. More specifically, if an aircraft had to fly all the way to the end of such a lengthy ISA before it could safely turn around, then the altitude of the aircraft at that point would likely be such that it could safely take almost any path back to the runway. This is contrary to providing pilots with the quickest safe route back to the runway in an emergency.

[00160] A solution to the aforementioned situation is represented in FIG. 22B. As shown, an ISA 135 is again located at the end of the runway 1 20, and the ISA termination point is again selected to serve as a convenient and safe point at which the aircraft of interest may initiate a path to other sectors, and also as a starting point for a subsequent straight sector within which the aircraft would be assured of having lateral maneuvering capability. However, it can also be seen that the turn geometry 140 of the given aircraft does not permit the aircraft to initiate a 180 degree turn at the termination point of the ISA 135 and still remain within the ISA. Consequently, an ISA extension 145 has been added to the end of the ISA 135. The ISA extension 145 is essentially a continuation of the ISA 135, and will typically have the same splay geometry and a trapezoidal shape similar to that of the ISA. The termination point of the ISA extension 145 may be the point where the aircraft of interest, flying along one lateral boundary of the ISA extension, can make a 180 degree turn and remain within the ISA extension. The termination point of an ISA extension may be defined in the same or a similar manner to that of an ISA. [00161 ] In the case of a SSDP that employs an ISA extension such as that shown in FIG. 22B, a departing aircraft still may safely begin transitioning to a flight path to other sectors upon reaching the end of the ISA 135. However, if the aircraft wishes to maintain a straight flight path from the runway 120 before entering a holding pattern, then the aircraft must fly to the end of the ISA extension 145.

[00162] As mentioned above and as illustrated in FIG. 21 and FIGS. 22A-22B, a straight out procedure segment, or straight segment (1 50, 1 55, 160), extends from the end of the ISA, or from the ISA extension if an ISA extension is present. The straight segment of a SSDP construction is the area from which a departing aircraft will normally make turns to other sectors (see e.g., FIG. 21 ). The straight segment is typically constructed with the same direction and splay rate as the ISA (or ISA extension). The termination point of the straight segment is the limit of the airport bounding area (100 in FIGS. 21 and 22A-22B). While the ISA and ISA extension may be mutually exclusive with respect to the sectors, the straight segment preferably is not. The straight segment may also have its own altitude boundary.

[00163] It can be observed in FIG. 21 , for example, that SSDP sectors and/or straight segments may be surrounded by buffer areas of some width. For purposes of illustration, a buffer area 1 15 is shown to exist only around Sector 1 of FIG. 21 . However, each of Sector 2, Sector 3, and Sector 4 may also have a buffer area, as may the central disc area 1 10. The width of each buffer area is preferably constant. The width of the buffer areas may be an input parameter that is supplied during the SSDP construction process. As indicated in FIG. 21 , the safe altitude of a given buffer area is preferably the same as the safe altitude of the sector or straight segment with which the buffer area is associated. The buffer areas provide for a factor of safety that, for example, compensates for accuracy differences in projected geometry. Obstacles within a buffer area may be analyzed and processed, such that aircraft practicing a SSDP have additional room in which to safely maneuver.

[00164] The exemplary SSDP diagram of FIG. 21 is shown to include a NAVAID restriction area 165. A NAVAID restriction area is typically applied when there are obstacles, terrain, and/or other features that prevent or inhibit use of the relied upon NAVAID within a particular area(s) of the SSDP bounding area. In the case of FIG. 21 , for example, there may be obstacles, terrain, and/or other features that prevent or inhibit use of the relied upon VOR-DME signals within the NAVAID restriction area 165. In other cases, a SSDP may not include a NAVAID restriction area, or may include more than one NAVAID restriction area.

[00165] In the example of FIG. 21 , the NAVAID restriction area 1 65 is constructed for the VOR-DME 1 05 at the center of the SSDP bounding area 100, and itself is bounded by two radials emanating from the VOR and by two DME arcs at different distances from the VOR-DME center point. This defines a generally trapezoidal NAVAID restriction area 165 that resides at some distance from the VOR-DME. Other NAVAID restriction area constructions are also possible. For example, a NAVAID restriction area may begin at the bounding area center point (normally the NAVAID center point) and extend outward to a DME arc. Alternatively, a NAVAID restriction area may begin at a DME arc located at some distance from a VOR-DME center point and extend outward to the limit of the airport bounding area.

[00166] NAVAID restriction areas also have altitudes associated therewith. For example, a NAVAID restriction area may have an altitude interval that, in conjunction with the other NAVAID restriction area boundaries, forms a NAVAID restriction volume. In some instances, NAVAID restriction areas may even be partitioned by one or more DME arcs, thereby allowing each NAVAID restriction area partition to have a different vertical interval.

[00167] In the case of a SSDP construction having a second NAVAID, the restriction areas associated therewith may be used to verify that the NAVAID signal is available along the line used to define the end of the ISA and ISA extension. The restriction areas of the second NAVAID are not used for intersections with sectors.

[00168] NAVAID restriction areas intersect with sector area geometry. A SSDP intersection algorithm may report each sector whose interior intersects any NAVAID restriction area interior, although the intersection between boundaries may not be reported. The intersection algorithm may not process sector buffer areas - i.e., if a NAVAID restriction area intersects a buffer and no intersection with a sector is found, the buffer intersection may not be reported. [00169] In vertical dimension, both sectors and NAVAID restriction areas may be constructed to have a flat top and a flat bottom surface - i.e. their boundaries may be defined by an altitude interval. The intersection algorithm may be designed to perform the corresponding altitude interval intersections and to filter out non-intersecting objects even if they intersect in 2-dimensional space. In FIG. 23 for instance, providing that they vertically intersect, Sector 2, Sector 3 and Sector 4 are reported to intersect NAVAID restriction areas NR1 , NR2 and NR3-1 and 3-2, respectively. Sector 1 and the straight sector do not have any intersection reported.

[00170] During geometry construction, NAVAID restriction areas may be used to verify that sector radials (i.e., ISA and ISA extension limiting radials and limiting DME arcs) are not obscured by NAVAID restrictions. That is, NAVAID restriction areas may be used to verify that sector radials do not go through any of the NAVAID restriction areas.

[00171 ] As should be clearly understood, a SSDP construction takes into account obstacles located with the various portions (e.g., sectors, central disc area, ISA, ISA extension, straight segment, buffer areas, etc.) of the airport bounding area. During SSDP construction, obstacle spatial representations may take the form of a cylinder that is centered at the obstacle (latitude, longitude) position. The radius of the cylinder is preferably equal to the obstacle horizontal accuracy. The height of the cylinder is preferably equal to the obstacle above mean sea level (AMSL) height (with reference to the earth gravitational model (EGM) 96 vertical datum), increased by the value of the obstacle vertical accuracy.

[00172] A SSDP obstacle and terrain analysis algorithm is provided. The algorithm generally performs several functions, including identification of various SSDP areas (e.g., ISA, ISA extension, straight segment, sector, and buffer areas) covering obstacle or terrain points being analyzed. The algorithm may also group all obstacles to the areas, create a pre-condition for area-specific processing, and present the resulting obstacles for each individual area. The algorithm may further provide coarse lateral filtering using SSDP coverage as well as filtering by one or more of various other techniques. The algorithm additionally performs flight path construction for each of the obstacles, and provides individual obstacle processing, specific to each type of SSDP area. In constructing SSDP flight paths, the algorithm uses flight path geometry and aircraft climb capabilities, to compute altitude augmentation for obstacles and to sort the information along the flight path, creating one or more pairs of distance- altitude values, where the distance is measured along the flight path from the brake release point, the end of TODA, the end of runway elevation (DER) or from the end of the ISA. A more detailed description of SSDP obstacle analysis and processing is provided below.

[00173] Obstacle data is analyzed and processed by a SSDP algorithm in order to develop flight paths, but may be analyzed and/or processed differently depending on the location of the associated obstacles. For example, and without limitation, obstacle data corresponding to a point or area near the limit of the airport bounding area may be processed differently than obstacle data corresponding to a point or area within the ISA.

[00174] For obstacles located within an ISA or ISA extension, the SSDP obstacle processing function assumes an aircraft of interest will follow a straight out climbing flight path using a specified climb gradient when traversing the ISA and ISA extension of a given SSDP. Since turns within the ISA and ISA extension are prohibited under a SSDP, obstacles and terrain points within an ISA or ISA extension are processed without the addition of any altitude correction for loss of climb gradient, which is described in more detail below. The obstacle processing function may deploy an obstacle filtering algorithm and may also perform an obstacle clearance check. The obstacle processing function normally outputs obstacle data that is passed by the obstacle filtering algorithm. However, it may be possible to optionally instruct the obstacle processing function to also pass data for filtered obstacles that penetrate the surface defined by the aircraft critical climb gradient value. Obstacles that penetrate the surface defined by the critical climb gradient value may be defined as failing the condition:

¾ + ^ * (^) > e_L (1 ) where H^MSL is ^tne above mean sea level elevation of the departure end of the runway; cg^CR is the critical value of the aircraft climb gradient expressed as a percentage; d^DER is the distance to the departure end of the runway; and H^MSL is the above mean sea level obstacle elevation, including vertical accuracy.

[00175] In contrast to obstacle processing in an ISA or ISA extension, obstacle processing in the straight segment and its buffer area (if present) assumes a turning flight path (e.g., to another sector). Consequently, the computation of derived obstacle elevation within the straight segment preferably takes into account the loss of climb gradient during turns (as described in more detail below).

[00176] As represented in FIG. 24A, in the absence of an ISA extension, the end of ISA 125 is preferably used as the starting point for flight path construction. Alternatively, when an ISA extension is present as shown in FIG. 24B, the end of the ISA extension is preferably used as the starting point for flight path construction. As described in more detail below, the analysis of obstacles within the straight segment involves an assumed aircraft flight path that, in at least one exemplary embodiment, includes one straight and up to three turning flight paths, with the climb rate of all flight paths having the same constant climb gradient. The climb gradient may be a user-specified value. There may be cases where some of the turning flight paths cannot be constructed.

[00177] In each exemplary SSDP construction represented in FIGS. 24A-24B, the straight line (1 ) represents the shortest flight path connecting the end of the ISA 125 (FIG. 24A) or ISA extension 145 (FIG. 24B) with the position of an obstacle 1 70 located within the respective straight segment 155, 1 60. The first turning flight path (2) consists of a straight leg parallel to the centerline of the straight segment (155, 160), followed by a 90 degree turn that ends at the location of the obstacle 170. The turn uses the larger (Ri) of two input aircraft turning radii. Flight path (3) in FIG. 24A begins at a vertex of the ISA 125 end line. Similarly, flight path (4) in FIG. 24B starts at the vertex of the ISA extension 145 end line. Both flight paths start with a turn toward the obstacle 1 70 using the larger (Ri) of the two input radii until the flight path heading is aligned with the obstacle 170. At that point, each flight path (3), (4) becomes a straight line to the obstacle 170. Once at the location of the obstacle 1 70, the flight paths change to circling flight paths 1 75 using the smaller (R2) of the two input aircraft turn radii, and climb in a spiral pattern until reaching the declared safe altitude of the straight segment 1 55, 1 60.

[00178] The altitude profile of the exemplary flight paths (1 )-(4) is linearly proportional to the distance along the given flight path as measured from the emanation point on the ISA end line (see also FIG. 24C). The distance (d) and altitude (h) are computed as:

h-AMSL = HAMSL + * d^ISA (3) ¾ = ¾¾ + ^ * (4) where a_t is the angle of i - th turns in degrees; R is the radius of turn, with k = 1 , 2 as applicable; n is the number of turns; I^s is the length of the straight leg; l'^SA is the length of the ISA, as measured at a given point on the ISA end line; h_AMSL is the above mean sea level altitude profile along the flight path; H^ L '^S the above mean sea level elevation of the departure end of the runway; H^' _SL is the above mean sea level elevation at the end of the ISA; eg is the climb gradient expressed as a percentage; and d'^SA is the distance measured along the flight path from the end of the ISA.

[00179] Notably, the length of the ISA (l^ISA) varies along the ISA end line in the exemplary SSDP of FIG. 24A. As a result, the AMSL elevation at the end of the ISA 1 25 may also vary along the ISA end line. The derived elevation of the obstacle 1 70 is thus computed by adding a height equivalent to the climb gradient decrement for each turning segment of the flight path preceding the obstacle position (see below). The derived obstacle elevation may be computed as follows:

h_AMSL = H_AMSL + ₁₀₀ * -^₀- *∑ ₌₁ R_{k t} (5) where h^_L is the above mean sea level derived obstacle elevation; H°^B _I ^S _SL is the above mean sea level obstacle elevation, including vertical accuracy; n is the number of complete or partial turns prior to reaching the obstacle location; cg^DEC is the absolute value of climb gradient decrement in turn, as a percentage; and a_t is the central angle of i - th turns, in degrees.

[00180] Obstacle assessment may be performed by calculating the values comprising the distance along the fight path to the obstacle; the profile altitude at the obstacle position (as a function of distance); the critical profile altitude at the obstacle position (as a function of distance); and the derived obstacle elevation (as a function of the overall turning distance prior to reaching the obstacle). Calculation of the distance (d'^SA) to the obstacle as measured along the flight path from the end of the ISA and the derived obstacle elevation h^_SL yields a number of distance-altitude pairs (d'^SA , h^_L) . Since each flight path shown in FIGS. 24A-24B has a different distance from the ISA 125 (or ISA extension 145) to the obstacle 1 70, a different length of turn, and hence a different climb gradient decrement, a unique distance-altitude pair (d'^SA , h^i) will be generated for each of the flight paths.

[00181 ] Referring again to FIGS. 24A-24B, the circling portions 175 of the flight paths (1 )-(4), flying over the obstacle 1 70, will create additional distance-altitude pairs (d'^SA , h^_L) - one for each full circle of each flight path. The critical profile altitude may be computed at each obstacle distance d'^SA to verify clearance with respect to the derived obstacle elevation h^_L , and the nominal profile altitude may be computed to stop circling when the flight profile reaches the safe sector altitude. The computed distance-altitude pairs are preferably sorted by distance and filtered. The process may be repeated for each obstacle and terrain point in the straight segment.

[00182] In FIGS. 24A-24B, the obstacle 170 is located at a sufficient distance from the start of the straight segment to permit turning flight paths thereto. However, in some cases an obstacle may be located within a SSDP straight segment at a point that is much closer to the end of the ISA or ISA extension - which can be problematic to SSDP construction. Such a situation is represented in FIG. 25. FIG. 25 includes the ISA 135, ISA extension 145 and straight segment 1 60 shown in FIG. 24B, but in this example, the location of the obstacle 180 is such that the distance between the obstacle and the start of the flight paths (2), (3) at the end of the ISA extension, is less than two times the turn radius of the aircraft of interest. Consequently, the obstacle 180 falls inside the turns of flight paths (2) and (3) if the turns are initiated at the ISA extension-straight segment boundary. Such a turn leg cannot be constructed.

[00183] Alternative flight paths may, however, be possible when an obstacle is close to an ISA or ISA extension end line, as represented in FIG. 25. One alternative flight path may be created by adding to the desired turning flight path an initial straight leg 185 that runs parallel to the centerline of the straight segment 160 and extends until the geometrical condition is achieved that makes a turn to the obstacle 1 80 possible. Such alternative flight paths are represented in FIG. 25 by the dashed lines associated with flight paths (2) and (3). Another alternative in such a situation - which is selected in FIG. 25 - is to only provide a straight flight path (1 ) to the obstacle 180 in such a situation.

[00184] As should be apparent, obstacles may also exist in other areas of a SSDP airport bounding area, such as within one or more sectors and/or in the central disc area. Obstacle processing in a sector may employ a similar algorithm to the algorithm used for obstacle processing in the straight segment. The sector obstacle processing algorithm may use the same formulae for distance, profile altitude, and derived obstacle elevation calculation as described above with respect to obstacle processing in the straight segment, but applied to different flight path geometry.

[00185] As illustrated in FIG. 26, the constructed flight paths for a sector emanate from the two vertices of the ISA end line when no ISA extension is present. When an ISA extension is present, the constructed flight paths for a sector would emanate from the two vertices of the ISA extension end line. In the exemplary embodiment represented in FIG. 26, the obstacle processing function constructs four flight paths (1 )-(4); two for each of the vertices. One of the flight paths (1 ), (3) emanating from each vertex uses the input minimum aircraft turn radius, while the other flight paths (2), (4) emanating from each vertex use the input maximum aircraft turn radius. The flight paths (1 )-(4) all start with a turning segment, which is continued until the aircraft heading is aligned with the location of the obstacle 190. At that point, the turn is discontinued and a straight leg is flown to the obstacle 190. Once at the obstacle location, the flight paths again change to circling 195 using the minimum aircraft turn radius value, and climbing in a spiral until reaching the safe altitude of the sector, as previously described.

[00186] Obstacle assessment and obstacle filtering for sectors may be the same as for the straight segment (see above). Sectors and straight segment coverage need not be mutually exclusive. Rather, obstacles processed in the straight segment may be processed a second time in the sector obstacle analysis. Some obstacles may even be processed a third time if said obstacles are located in a sector buffer.

[00187] Obstacle processing in the central disc area and the central disc area buffer may use the same algorithm employed for processing obstacles in a sector area. Unless found inside a sector buffer, obstacles falling inside the central disc area may be excluded from sector processing.

[00188] As with the case of the straight segment, as described above, obstacles within a sector may be sometimes located very close to an ISA lateral boundary or an ISA extension lateral boundary. Such a situation is represented in the SSDP diagram of FIG. 27, which again includes an airport bounding area 200, a NAVAID 205 at which the bounding area 200 is centered, a runway 210, an ISA 215, a straight segment 220, and multiple sectors of which only Sector 1 and Sector 2 are identifiable.

[00189] As represented in FIG. 27, an obstacle 225 is located sufficiently close to the left radial boundary of the ISA 210 that the distance between the obstacle 225 and the start of a flight path from the ISA end line left vertex is less than two times the turn radius of the aircraft of interest. As discussed above with respect to the SSDP diagram of FIG. 25, in such a case, the obstacle 225 falls inside the turn of the aircraft and a direct turn segment to the obstacle cannot be constructed. Therefore, as depicted in Detail A of FIG. 27, in order to construct a flight path to the obstacle 225, the processing function extends from the left radial (the radial in close proximity to the obstacle 225) of the ISA 215 a straight flight path leg 230 that is aligned with the left radial. The length of the straight leg 230 is sufficient to permit the geometrical condition required to make a subsequent turn to the obstacle 225 possible.

[00190] As mentioned above, obstacles may also be located in a buffer area. Obstacle processing in buffer areas may be the same as for a sector around which the buffer is constructed. Because the buffer of a given sector will typically overlap a neighboring sector(s), obstacles in a buffer area may be processed twice - once for the sector, and a second time for the buffer area.

[00191 ] While various exemplary flight paths to obstacles have been presented in FIGS. 24A-27, it should be realized that flight paths based on alternative constructions may also be used. One set of alternative flight paths is depicted in the SSDP diagram of FIG. 28, in which an airport bounding area 250, a NAVAID 255 at which the bounding area 250 is centered, a runway 260, an ISA 265, a straight segment 270, and multiple sectors of which only Sector 1 and Sector 2 are identifiable.

[00192] In this example, a series of flight path legs 275 from the ISA 270 to the location of the obstacle 280 diverge from the normally calculated flight paths 285. More specifically, instead of employing constant radius turns followed by a straight segment - as used by the normally calculated flight paths 285 shown in solid lines - each of the alternative flight paths 275 shown in dashed lines splay from the corresponding original flight paths at some predetermined rate. In this particular example, the splay rate is 1 :8 (i.e., for each 8 units of distance, there is 1 unit of offset) until reaching a 3,000 foot distance from the original path, whereafter the same offset is maintained. The use of other splay rates is possible in other embodiments.

[00193] Because the alternative flight path construction technique utilizes a more critical combination of the length of turn and the overall length available for climbing, a larger derived obstacle elevation or lower profile altitude, or both, may be realized. In comparison to the exemplary flight paths represented in FIGS. 24A-27, the radius of turn in the alternative flight path construction is different than the input radius values, the offset geometry at the outer side of the turn in the alternative flight path construction under-shoots the obstacle position and ends at the offset distance from the obstacle, and the offset geometry at the inner side of the turn in the alternative flight path construction over-shoots the obstacle position and ends at the offset distance from the obstacle.

[00194] As discussed above, the SSDP construction process employs one or more obstacle filtering algorithms. In one exemplary multi-step obstacle filtering process, which is represented in FIGS. 29A-29E, an obstacle filtering algorithm processes the aforementioned distance-altitude pairs (d'^SA , h M^V _SL) (sorted by distance d^ISA) separately for groups of obstacles Oi - Og located in the straight segment or sector of a SSDP airport bounding area and discards any obstacle or terrain point through the multi-step process of elimination by obstacle height, elimination by minimum profile, and elimination by maximum climb gradient. [00195] In the case of elimination by obstacle height, the obstacle filtering algorithm discards any obstacle or terrain point that is of lower elevation (has smaller h^_SL) than an earlier (in terms of d'^SA ) obstacle or terrain point. Such an elimination technique is represented in FIG. 29B, where obstacles 0₄ and O5 in are lower than obstacle O3, and where obstacle Os is lower than obstacle O7 - meaning that obstacles 0₄, O5 and Os may be discarded.

[00196] In the case of elimination by minimum profile, the obstacle filtering algorithm discards any obstacle or terrain point that is lower than a profile defined by an aircraft minimum climb gradient and minimum acceleration height. Such an elimination technique is represented in FIG. 29C, where obstacle O1 is eliminated because its height falls below the minimum profile 300 defined by the minimum climb gradient and minimum acceleration height of the aircraft of interest.

[00197] In the case of elimination by maximum climb gradient, the obstacle filtering algorithm discards any obstacle or terrain point that would be dwarfed by a subsequent obstacle - meaning that if the subsequent obstacle would be cleared, the preceding obstacle would also be cleared. Such an elimination technique is represented in FIG. 29D, where obstacle O7 is below the maximum nominal climb gradient line extending from obstacle Og - meaning that if obstacle Og is cleared then obstacle O7 will also be cleared, and that obstacle O7 may be eliminated. Note, however, that obstacle ΟΘ is not eliminated because obstacle ΟΘ extends above the maximum nominal climb gradient line extending from obstacle Og.

[00198] FIG. 29E represents the results of the exemplary obstacle filtering process. Particularly, it can be observed that of the nine obstacles present in the straight segment or sector of interest, the obstacle filtering algorithm has eliminated all but four of the obstacles, i.e., obstacles O2, O3, ΟΘ, and Og. As a result, flight path calculation need only be concerned with four obstacles instead of nine.

[00199] SSDP flight path geometry construction may perform turn processing by relying on a simple, steady, horizontal coordinated turn model. In such a model, there is no tangential acceleration by the aircraft, the aircraft does not sideslip, and the trust angle of attack is neglected. In such a model, a turn is initiated by rolling the aircraft to produce an unbalance in static equilibrium by rotating the lift vector (L) out of vertical plane. The wings of the aircraft are banked at a constant angle φ, and the lift vector (L) is inclined at angle φ toward the center of the turn. This creates a centripetal component of the lift vector (L) that has a magnitude of Lsin((p). The centripetal component acts in a horizontal plane, perpendicular to the flight path, causing the aircraft to turn in a circular path with a radius of curvature (R).

[00200] SSDP construction may specify two aircraft climb gradients - nominal climb gradient and critical climb gradient. Nominal climb gradient is used to model flight path profile and detect distance when the profile reaches sector safe altitude in order to terminate processing for an obstacle. This flight path starts at the end of ISA or ISA Extension. Critical climb gradient is used to perform obstacle clearance. Obstacles penetrating a surface defined by this climb gradient may trigger a warning message and would not be filtered out. This surface starts at the runway departure end elevation.

[00201 ] With respect to the critical climb gradient surface penetration, obstacle processing may have two modes. A first mode may be considered a "warning only" mode, meaning the obstacle processing function will generate a warning, but will not create list of penetrating obstacles. A second mode may be considered a "penetrating obstacle report" mode, meaning the processing function will generate a separate list of filtered obstacles that penetrate the critical climb gradient surface.

[00202] One example of a SSDP chart producible by an exemplary system and method embodiment is illustrated in FIG. 30. As can be observed, the airspace surrounding the Fort Lauderdale Hollywood International Airport (KFLL/FLL) has been depicted to show a simple "single" sectored departure along with other aeronautical features of relevance. The sectored area in which the aircraft must remain is depicted by the large circle identified on its boundary by the central VOR (FLL 1 16.5) and the distance from the VOR/DME that the aircraft must remain (i.e., 25NM). The altitude that the aircraft must attain to avoid obstacles in any portion of the sector is identified beneath the name of the common sector "A" as 21 00ft Pressure Altitude. Closer to the runway is a small polygon which is referred to as the straight area. The straight area is the area within which an aircraft must initially attempt to fly along the extended runway centerline prior to turning into the sector. The straight area is also depicted in greater detail on the lower left hand part of the SSDP diagram, and is defined both by a series of latitude and longitude points, as well as a distance from a common NAVAID which, in this example, is the 2NM arc (depicted as a straight line on the top of the polygon) listed as FLL 2NM.

[00203] The exemplary SSDP of FIG. 30 also presents several other pieces of information that are important for pilots to consider during the use of the SSDP. For example, at the center of the SSDP chart is a depiction of the runways, including the runway for which the SSDP is intended. A compass, indicating magnetic variation from True North, is also indicated in the top right portion of this exemplary SSDP chart. The polygons outlined in blue on the SSDP chart represent different airspace boundaries that are controlled by communications over different frequencies. Furthermore, the grey sections of the primary sector indicate areas where the NAVAID used to create the primary sector may not provide a reliable reading. Note also the longitude and latitude coordinates of the ISA vertices at the bottom left of the chart.

[00204] Another example of a SSDP chart producible by an exemplary system and method embodiment is illustrated in FIG. 31 . As can be observed, the airspace surrounding the Fort Smith Regional Airport (KFSM/FSM) has been divided 5 navigable sectors A through D, plus a "STRAIGHT" segment. When using this exemplary SSDP, a pilot is able to choose which of the sectors, or combinations thereof, the pilot intends to stay within in the event of an engine failure or other emergency during takeoff. A given sector may only be entered into after maintaining a flightpath through the ISA depicted in the lower left corner of the SSDP chart and the ISA extension depicted in the lower right corner of the SSDP chart. This exemplary SSDP chart also indicates that larger aircraft experiencing an engine failure or other emergency situation must delay entry into Sector C or Sector D until the aircraft has passed through the ISA extension depicted in the lower right corner of the SSDP chart. This required additional straight ahead flying distance without turning, ensures that the higher speeds and greater turn radii associated with larger aircraft will be contained completely within the straight segment. In addition to the navigable sectors, this exemplary SSDP chart also indicates that the straight segment safe altitude is 2100 feet, and depicts terrain in shades of brown and hydrography information in shades of gray. Assorted notes are also incorporated into this SSDP chart example, including caution messages associated with Sectors A and D to indicate A-1 0 Warthog military aircraft could be flying low to the ground in those sectors.

[00205] A non-exhaustive collection of unique symbols that may be used on special departure procedure (SDP) charts producible by exemplary system and method embodiments is provided in FIG. 32.

Dynamic Charting

[00206] FIGS. 33A-33B illustrates how the charting functionality of an exemplary system and method embodiment may permit a user to customize charts, such as by controlling the various layers that form a given chart. In this regard, FIG. 33A depicts an exemplary layer control menu where a user has elected to turn off Sector A and Sector C of the SSDP chart shown in FIG. 31 . FIG. 33B represents the SSDP chart of FIG. 31 with Sector A and Sector C turned off according to the menu selections of FIG. 33A. Other layers may also be present and be controllable in other charts, as may other chart functionality.

[00207] At least from the foregoing written description of exemplary system and method embodiments and the related drawing figures, it should be apparent that one aspect thereof is a shift toward the presentation of information in a visual, rather than textual, numeric or other format. For example and without limitation, exemplary system and method embodiments described herein may permit a user to better visualize the geospatial area around an airport, to visualize geospatial conflicts (and the de-confliction thereof), to visualize aircraft performance, and to visualize the risk associated with decisions about aircraft performance, flight operations, etc. Consequently, exemplary system and method embodiments described herein may include dynamic aeronautical charting functionality that is capable of presenting, among other information, flight procedures, predicted aircraft locations, and terminal area information, with real time reaction to changes in information.

[00208] The dynamic aeronautical charting functionality of an exemplary system embodiment may be employed in the production of a multitude of different charts related to flight planning and flight operations. For example, as shown in FIG. 34, a dynamic aeronautical charting product/function of an exemplary system may be used to produce a SID chart. This exemplary SID chart is for the AD LAN 1 B departure procedure, which is effective for both runway 20 and runway 29 of the Keflavik International Airport (BIKF) in Iceland, but charts for other runways of other airports may also, of course, be generated. Similarly, a dynamic aeronautical charting product/function of an exemplary system may be used to produce an instrument approach chart as depicted in FIG. 35. The exemplary instrument approach chart of FIG. 35 is a GPS approach chart for Runway 01 L of the Andrews Airforce Base (KADW) in Camp Springs, Maryland, but instrument approach charts for other runways of other airports may also be generated. Another such instrument approach chart is shown in FIG. 36, with this exemplary chart being a DVOR/DME instrument approach chart for Runway 20 of the Paya Lebar Airport (WSAP) in Singapore.

[00209] The dynamic aeronautical charting functionality of an exemplary system embodiment may also interact with other products/functions of the system to generate relevant charts or other visual presentations (see generally the ACE element of FIG. 2 in this regard). For example, a dynamic aeronautical charting product/function of an exemplary system may receive an output of information from a terminal area and airport management product/function (or another product/function) of the system and use said information to produce an terminal/airport area chart, an aviation virtual surface chart (see, e.g., FIGS. 1 1 - 12), or any of a multitude of other charts associated with airport management, flight operations planning, etc. Similarly, for example, a dynamic aeronautical charting product/function of an exemplary system may receive an output of information from a performance calculation product/function (or other product/function) of the system and use said information to produce a visual indication of aircraft performance, a visual indication of risk in consideration of performance (see, e.g., FIG. 15), etc.

[00210] The dynamic aeronautical charting functionality of an exemplary system embodiment may also include an enhanced ability to visually present an aircraft flight path, including the integration of previously accepted or selected engine failure procedures, or procedures associated with other normal and non- normal operating configurations. This ability is reflected, for example, in the RSDP charts of FIGS. 17-19 and the SSDP charts of FIGS. 30-31 . Another such exemplary chart that is representative of such a charting ability is illustrated in FIG. 36. As can be observed, the chart of FIG. 37 is directed to a departure from a particular runway of a given airport (i.e., Runway 17R of Henderson Executive Airport in Las Vegas, Nevada), and includes a detailed visual depiction of a planned or suggested waypoint-based flight path for both an all engines operative (AEO) or one engine inoperative (OEI) departure situation.

[00211 ] The dynamic aeronautical charting functionality of an exemplary system embodiment may be further operative to facilitate or enhance the chart generation and/or analysis process. For example, as represented in FIGS. 38- 39, the dynamic aeronautical charting functionality of exemplary system and method embodiments described herein may be adapted to automatically highlight a graphical depiction of flight procedure information (e.g., a route segment) when a user selects (e.g., clicks on or taps on) corresponding flight procedure information presented in textual form, or to automatically highlight flight procedure information presented in textual form when a user selects a graphical depiction of said flight information. In this particular example, the result is that the associated textual and graphical flight procedure information (route segments) are thereafter highlighted in green.

[00212] The dynamic aeronautical charting functionality of an exemplary system embodiment may be further employed in the process of predictive flight path modeling, which may be a feature of the dynamic aeronautical charting product/function, a performance calculation product/function, or some other product/function or combination of products/functions of an exemplary system embodiment. More specifically, a dynamic aeronautical charting product/function of an exemplary system embodiment may be used to visually display a predicted flight path, such as a predicted departure flight path.

[00213] One exemplary embodiment of visually displaying a predicted flight path is depicted in FIG. 40. FIG. 40 is intended to be representative of a SID chart, but with textual and other information removed for clarity. As shown in FIG. 40, the planned/expected SID departure from this hypothetical runway generally calls for a right turn at the 5 nautical mile mark from runway end, followed by a slow turn back to the left to intercept the VOR path to an initial waypoint indicated as WP 1 .

[00214] The exemplary enhanced chart of FIG. 40 also novelly includes a predicted flight path that deviates from the anticipated SID flight path. Predictive flight path modeling may be performed, for example, as briefly described above. An exemplary system and method embodiment may calculate the predicted flight path based on a number of factors, such as without limitation, aircraft performance and/or weight and balance factors, and environmental factors such as temperature, pressure, crosswind speed, etc.

[00215] In any case, it has been determined in the example of FIG. 40 that, for one or more reasons, a given aircraft of interest departing from the depicted runway will most likely deviate from the planned SID flight path. This deviation is indicated (by the dashed line) on the chart of FIG. 40 as the predicted actual flight path of the aircraft during departure. As may be observed, a visual depiction of the predicted actual flight path versus the planned SID flight path may be very useful, as in this example where such a deviation alters the flight path around an obstacle.

Airborne Emergency Decision-Making

[00216] As would be well understood by one of skill in the art, flight planning - particularly with respect to flights that require extended navigation over terrain, over water, or over areas in which suitable airports are unavailable for landing - may be challenging. During flight planning, there is a need for a visual means of ensuring there exists an escape path to airports within gliding range of a planned flight path. Similarly, there is a need for a visual means of ensuring the presence of airports along the planned flight path at which a special missed approach procedure (SMAP) may be executed.

[00217] Other flight planning difficulties also exist. For example, scheduled air carriers (FAR Part 1 21 operators) and commuter and on-demand carriers (FAR Part 135 operators) are often faced with challenging single engine net ceiling and terrain clearance issues (e.g., 7,1 00ft; Anti-Ice On). Such operators need a better flight planning solution than is currently available. Furthermore, there is a need for dispatchers and flight followers to be able to see and react to changes in the flight path of an aircraft with updated performance limitations as the flight proceeds.

[00218] Analysis has also revealed that, while flight planning that properly considers diversions to alternate airports in emergency situations actually requires a continued engineering analysis, most operators do not undertake such additional analysis. Similarly, most operators do not want to limit takeoff or landing weight to accommodate such a possibility.

[00219] In light of these industry needs and issues, an exemplary system and method embodiment according to the present application may further include airborne emergency decision-making functionality. More specifically, an exemplary system may include an airborne emergency decision-making product/function that is adapted to provide visual feedback to relevant aviation industry personnel regarding the safest paths to take when experiencing an enroute emergency situation. Such airborne emergency decision-making functionality is of particular, but not exclusive, importance with respect to flights that require extended navigation over terrain, over water, or over areas in which suitable airports are unavailable for landing. Such functionality and the information provided thereby may be relevant to aviation industry personnel such as, for example and without limitation, flight crews, dispatchers, flight followers, pilots and controllers.

[00220] An airborne emergency decision-making product/function of an exemplary system embodiment may be operative to, for example and without limitation: create a visual performance solution that satisfies enroute regulatory compliance and risk management requirements; support advanced terrain clearance calculations for all operating regulations; support advanced extended- range twin-engine operational performance standards (ETOPS) for all operating regulations; create a seamless transition between terminal area aircraft performance and enroute aircraft performance that allows a user to manage the risk levels; and create a solution that simultaneously supports pilots and planners in mobile disconnected mode or in an ASD/Flight planning tie-in. As with other possible products/functions of an exemplary system embodiment, an exemplary airborne emergency decision-making product/function may utilize the same aeronautical, geospatial and other data stored in a common database (e.g., TEAMDB). Utilizing common data ensures, for example, that users are flight planning based on the same terrain and obstacle considerations.

[00221 ] An airborne emergency decision-making product/function of an exemplary system embodiment may also provide a semi-automated method for the sectorized handling of potential descent paths based on common navigational points over terrain, or based on an aviation virtual surface (AVS). An exemplary visual depiction of such airborne emergency decision-making functionality - including the sectored handling of potential descent paths - appears in FIG. 41 .

Regulation and Compliance

[00222] Yet other exemplary system and method embodiments may include a visual interface to regulatory compliance and performance impact analysis. More particularly, an exemplary system embodiment may be adapted to collect, visualize, and associate collections of, textual information, data tables, business processes, regulations, manuals, guidance materials and other sources of an electronic nature through a semi-automated or fully automated process

[00223] An exemplary visual interface to regulatory compliance and performance impact analysis may be functional to establish connections between different areas of aviation services, which promotes information sharing and use. An exemplary visual interface to regulatory compliance and performance impact analysis may be functional to encourage community interaction, thereby helping to ensure that information is as current and accurate as possible. An exemplary visual interface to regulatory compliance and performance impact analysis may be functional to more clearly indicate to a user, such as through a visual presentation of information, how a given change will affect other systems, rules, compliance, etc. An exemplary visual interface to regulatory compliance and performance impact analysis may also be functional to notify users if relevant performance or other data changes.

[00224] Additionally, because much of the information that will be collected, visualized, and/or associated by an exemplary visual interface to regulatory compliance and performance impact analysis is likely to be textual in nature, an exemplary visual interface product/function may be adapted to parse complex textual information into components which can more easily be linked or associated with other textual information in a graphical database, for ultimate visualization to an end user. A diagrammatic functional representation of one exemplary visual interface to regulatory compliance and performance impact analysis product/function is shown in FIG. 42.

Products

[00225] As briefly discussed previously, an exemplary system embodiment may comprise a suite of individual, but possibly interacting, products. Such an embodiment may be analogous to, for example, the Microsoft® Office suite of products, wherein a plurality of individual products/applications provide different functionality within the product suite, and wherein at least some of the products are able to share information with or use information from some of the other products. Access to the various product functionality in such an embodiment may be controlled, for example, by controlling the purchase of, or the license associated with, each product. Alternatively, all of the available products of an exemplary system may be present but locked out or otherwise deactivated based on user license level, etc.

[00226] Alternatively, all of the functionality of the aforementioned series of individual products of a product suite may instead be imparted to one product. In such an exemplary system embodiment, a user may simply be directed to select the type of task to be performed as opposed to selecting a particular product that the user assumes to be the correct product for performing the desired task. Access to various functionality may again be controlled, for example, by license level, etc.

[00227] As also previously described, the various products/functions or areas of various functionality of an exemplary system embodiment, may retrieve (and/or send) data to a common database of aeronautical, geospatial, and/or other information. The various products/functions or areas of various functionality of an exemplary system embodiment may also share information in various ways to accomplish a particular task. For example, a charting engine may receive data from one or more system products/functions, in order to visually present information to a user.

[00228] It should also be noted that the various products/functions of an exemplary system embodiment may all or selectively be provided with the ability to operate in a cloud-based environment, such as but not limited to the ability to communicate with a common database via a web browser and mobile applications. At least some of the various products/functions of an exemplary system embodiment may also, or instead, be adapted so as to be provided as mobile solutions, such as on a non-connected or intermittently connected mobile device.

[00229] While certain exemplary system and method embodiments are described in detail above, the scope of the invention is not considered limited by such disclosure, and modifications are possible without departing from the spirit of the invention as evidenced by the following claims:

Claims

WHAT IS CLAIMED IS:

1 . A sectored departure procedure for use by an aircraft departing an airport of interest, comprising:

a bounding area surrounding the airport and centered at a point of interest relative to the airport, the bounding area partitioned into a plurality of sectors; a central bounding area centered within the airport bounding area and serving as a transition zone between sectors;

an identified departure runway with a departure end;

an initial straight area at the departure end of the runway, the initial straight area having a defined end;

a straight segment beginning at the end of the initial straight area and extending to an outer limit of the airport bounding area;

a safe altitude assigned to at least the straight segment and each of the sectors; and

at least one defined flight path for the aircraft to at least one obstacle located in the straight segment or at least one of the sectors.

2. The sectored departure procedure of claim 1 , wherein the airport bounding area and central bounding area are of circular cross-section.

3. The sectored departure procedure of claim 1 , wherein sector partitioning is defined by a plurality of radials emanating from the center point of the airport bounding area.

4. The sectored departure procedure of claim 3, wherein sector partitioning is further defined such that:

a given sector Si is defined from the central bounding area to the outer limit of the airport bounding area, between an i-th and i+1 radial;

where i=2 ...n; and

the last sector is defined between the n-th and first radial.

5. The sectored departure procedure of claim 1 , wherein the initial straight area is defined by: opposing lateral radials (bearing lines) emanating from the center point of the airport bounding area;

a beginning line located at the departure end of the runway; and an end line located outbound of the beginning line.

6. The sectored departure procedure of claim 5, wherein the end of the initial straight area is defined by a geometric element selected from the group consisting of a limiting radial, a geodetic arc centered at the airport bounding area center point, and a distance measured along an initial straight area bearing line.

7. The sectored departure procedure of claim 1 , wherein the end of the initial straight area occurs at the first point where the aircraft, flying along one lateral boundary of the initial straight area, can make a 1 80 degree turn and still remain within the initial straight area.

8. The sectored departure procedure of claim 1 , further comprising an initial straight area extension interposed between the initial straight area and the straight segment.

9. The sectored departure procedure of claim 1 , wherein the straight segment has substantially the same direction and splay rate as the initial straight area.

10. The sectored departure procedure of claim 1 , wherein the at least one defined flight path emanates from the end of the initial straight area and is comprised of an initial turn to a heading that results in a straight path to the at least one obstacle.

1 1 . The sectored departure procedure of claim 10, wherein when the at least one flight path reaches the location of the at least one obstacle, the flight path transitions to a climbing turn with a spiral trajectory that allows the aircraft to reach the safe altitude assigned to the straight segment or sector in which the at least one obstacle is located.

12. The sectored departure procedure of claim 1 , wherein a distance-altitude value pair is assigned to each flight path.

13. The sectored departure procedure of claim 1 , wherein the airport bounding area is centered at a navigational aid (NAVAID).

14. The sectored departure procedure of claim 13, wherein the NAVAID is selected from the group consisting of a VOR, a DME, a NDB, a TACAN, and combinations thereof.

15. The sectored departure procedure of claim 1 , further comprising a buffer area of some width extending around at least the sectors of the airport bounding area.

16. The sectored departure procedure of claim 1 , further comprising at least one NAVAID restriction area, the NAVAID restriction area coinciding with a portion of the airport bounding area in which signals from the NAVAID are blocked or inhibited.

17. A method for creating a sectored aircraft departure procedure, comprising:

selecting an airport of interest;

selecting a runway of interest at the airport and identifying a departure end of the runway;

defining an airport bounding area surrounding the airport and centered at a point of interest relative to the airport;

partitioning the bounding area into a plurality of sectors based at least in part on the selected runway;

defining a central bounding area centered within the airport bounding area and serving as a transition zone between sectors; defining an initial straight area at the departure end of the runway based on known performance characteristics of the aircraft, the initial straight area ending at some distance from the departure end of the runway;

defining a straight segment beginning at the end of the initial straight area and extending to an outer limit of the airport bounding area;

analyzing, filtering and processing obstacles located within at least the initial straight segment and the sectors of the airport bounding area;

based on the processed obstacle data, determining a safe altitude within which the aircraft may maneuver laterally within at least the straight segment and each sector; and

calculating at least one defined flight path for the aircraft to at least one obstacle in the straight segment or at least one of the sectors.

18. The method of claim 17, further comprising, determining based at least in part on aircraft performance characteristics, whether to interpose an initial straight area extension between the initial straight area and the straight segment.

19. The method of claim 17, wherein analyzing and filtering the obstacles further includes:

identifying the sectors, central disc area, initial straight area, and straight segment within the airport bounding area in which obstacles reside; and

grouping all obstacles by area type.

20. The method of claim 17, wherein processing is performed on each individual obstacle, and the processing methodology employed is specific to the type of area within which a given obstacle resides.

21 . The method of claim 17, wherein:

obstacles located within the initial straight area are processed under the assumption that the aircraft will follow a straight out climbing flight path using a specified climb gradient when traversing the initial straight area; and

no altitude correction for loss of climb gradient is applied to the processed obstacles.

22. The method of claim 17, further comprising:

establishing an aircraft critical climb gradient value for flight through the initial straight area; and

identifying obstacles within the initial straight area that will penetrate a surface critical climb gradient by applying the formula:

CR

J DER ₊ J^CL (₍jDER > _HOBS

^NAMSL AMSL

where H^ L '^{s tne} above mean sea level elevation of the departure end of the runway; cg^CR is the critical value of the aircraft climb gradient expressed as a percentage; d^DER is the distance to the departure end of the runway; and H^MSL is the above mean sea level obstacle elevation, including vertical accuracy.

23. The method of claim 17, wherein:

obstacles located within the straight segment or a sector are processed under the assumption that the aircraft will follow a turning flight path; and

a derived elevation for an obstacle located within the straight segment or a sector is calculated taking into account the loss of aircraft climb gradient during turns.

24. The method of claim 23, wherein the at least one defined flight path for the aircraft in the straight segment or in a sector is defined to include one straight and up to three turning flight paths, with the climb rate of all flight paths having the same constant climb gradient.

25. The method of claim 17, wherein the calculation of a flight path includes: the use of flight path geometry and aircraft climb capabilities to calculate altitude augmentation for obstacles;

sorting of obstacle information along the flight path; and

the creation of distance-altitude values that are associated with each flight path, the distance measured along a given flight path from a selected starting point.

26. The method of claim 25, wherein the selected flight path starting point is selected from the group consisting of an aircraft brake release point, the end of TODA, the departure end of runway elevation, and the end of the initial straight area.

5

27. The method of claim 17, wherein:

calculation of a flight path within the straight segment or a sector includes assigning an altitude profile to the flight path;

the altitude profile is linearly proportional to the distance along the given 10 flight path as measured from a flight path emanation point; and

a distance (d) and altitude (h) associated with the altitude profile are computed using the formulae: d_{ISA = l}s ₊ f ^

L-> 180°

i=i

_H _ LJISA , ISA

^NAMSL — ^NAMSL QQ

1 ς

N HA^ISM^ASL -— ^N HA^D 4- M^ERSL ⁺ ^ °QQ *

^L * ¹ l'^SA where a_t is the angle of i - th turns in degrees; R is the radius of turn, with k = 1 , 2 as applicable; n is the number of turns; I^s is the length of the straight leg; l'^SA is the length of the initial straight area, as measured at a given point on the initial straight area end line; h_AMSL is the above mean sea level altitude profile 20 along the flight path; H^MSL '^{s tne} above mean sea level elevation of the departure end of the runway; H^MSL is ^tne above mean sea level elevation at the end of the initial straight area; eg is the aircraft climb gradient expressed as a percentage; and d^lSA is the distance measured along the flight path from the emanation point thereof.

25

28. The method of claim 17, wherein a derived elevation of an obstacle in the straight segment or in a sector is calculated using the formula:

DEC ^N

h-AMSL ⁼ H_AMSL + ^ QQ * gg° * 2-1 ^^{K <XI}

i=i where is the above mean sea level derived obstacle elevation; H ^S _SL is the above mean sea level obstacle elevation, including vertical accuracy; n is the number of complete or partial turns made by the aircraft prior to reaching the obstacle location; cg^DEC is the absolute value of climb gradient decrement in turn for the aircraft, as a percentage; and a_t is the central angle of i - th turns, in degrees.

29. The method of claim 17, wherein multi-step obstacle filtering is employed.

30. The method of claim 29, wherein the multi-step obstacle filtering process includes obstacle elimination by obstacle height, elimination by minimum profile, and elimination by maximum climb gradient.

31 . The method of claim 30, wherein:

elimination by obstacle height discards any obstacle in a given area that is of lower elevation than an obstacle that will be encountered earlier in the flight path;

elimination by minimum profile discards any obstacle that is lower than a profile defined by an aircraft minimum climb gradient and minimum acceleration height; and

elimination by maximum climb gradient discards any obstacle that is lower in elevation than an immediately subsequent obstacle in the flight path, such that if the subsequent obstacle would be cleared, the preceding obstacle would also be cleared.

32. The method of claim 17, wherein an aircraft flight path is calculated using two climb gradients, comprising:

a nominal climb gradient that is used to model flight path profile and detect distance when the profile reaches a safe altitude in the straight segment or in a sector; and

a critical climb gradient that is used to calculate obstacle clearance.

33. The method of claim 17, further comprising presenting the sectored aircraft departure procedure in a graphic form viewable by a user.

34. A computerized system for constructing a sectored aircraft departure procedure, comprising:

at least one database containing aeronautical and geospatial data;

a user interface adapted to permit user selection or identification of an airport and aircraft of interest, and to accept user data input relative to sectored aircraft departure procedure construction;

a terminal area management component in communication with the at least one database and adapted to retrieve geospatial data therefrom;

a performance calculation component in communication with the terminal area management component and adapted at least to determine aircraft performance characteristics;

a computation module in the form of a global procedure designer (GPD), the GPD in communication with the terminal area management component and the performance calculation component;

an obstacle filtering and processing algorithm associated with the GPD; and

a flight path calculation algorithm associated with the GPD;

wherein the GPD is programmed to use data from the user, the terminal area management component, the performance calculation component, or some combination thereof, and to:

define an airport bounding area surrounding the airport and centered at a point of interest relative to the airport,

partition the bounding area into a plurality of sectors based at least in part on the user-selected runway,

construct a central bounding area centered within the airport bounding area to serve as a transition zone between sectors,

construct an initial straight area that begins at the departure end of the runway and ends at some distance therefrom, the initial straight area construction based at least in part on performance characteristics of the aircraft as provided by the performance calculation component, construct a straight segment that begins at the end of the initial straight area and extends to an outer limit of the airport bounding area, use the obstacle filtering and processing algorithm to analyze, filter and process obstacles located within at least the initial straight segment and the sectors of the airport bounding area,

based on data from the analyzed and filtered obstacles, determine a safe altitude within which the aircraft may maneuver laterally within at least the straight segment and each sector, and

use the flight path calculation algorithm to calculate at least one defined flight path for the aircraft to at least one obstacle in the straight segment or at least one of the sectors.

35. The computerized system of claim 34, further comprising:

a web interface that is adapted to effectuate user selections and data input via the Internet; and

a data interface in communication with the web interface and the at least one database.