METHODS AND SYSTEMS FOR AUTOMATIC ROUTE PLANNING

Disclosed are methods, systems, and non-transitory computer-readable medium for controlling a vehicle. In one embodiment, a first route plan having a starting point and an ending point may be generated, wherein the first route plan is based on at least one parameter and wherein the first route plan is configured to cause the vehicle to generate an overpressure event over areas where it is undesirable to have the environmental impact of the overpressure event. An operator input may then be received to change at least one operating parameter of the vehicle, and a second route plan may be generated based, at least in part, on inputs. The first route plan and the second route plan may be displayed on a display. Upon receiving inputs to select a route plan displayed on the display, actuator instructions are generated to control the vehicle to follow the selected route plan.

TECHNICAL FIELD

Various embodiments of the present disclosure relate generally to methods and systems for an automatic route planning of a vehicle and, more particularly, to methods and systems for an automatic route planning for supersonic flight of a vehicle.

BACKGROUND

Regulatory authorities currently restrict over-land supersonic flight of civilian aircraft (A/C) throughout much of the populated world. In the United States, for example, current Federal Aviation Administration (FAA) regulations prohibit supersonic flight of civilian NC over land. Such restrictions are generally motived by noise abatement rationale and a desire to protect ground structures, such as building windows, from damage due to the pressure waves generated during supersonic air travel.

SUMMARY OF THE DISCLOSURE

According to certain aspects of the disclosure, systems and methods are disclosed for route planning of a vehicle.

In one embodiment, a method is disclosed for controlling a vehicle. The method comprises: generating a first route plan having a starting point and an ending point, wherein the first route plan is based on at least one parameter and wherein the first route plan is configured to cause the vehicle to generate an overpressure event; receiving an operator input to change at least one operating parameter of the vehicle; generating a second route plan based, at least in part, on the operator input; displaying the first route plan and the second route plan on a display; receiving an operator input to select a route plan displayed on the display; and generating actuator instructions to control the vehicle to follow the selected route plan.

In accordance with another embodiment, a system for controlling a vehicle is disclosed. The system comprises: a memory storing instructions; and a processor executing the instructions to perform a process including: generating a first route plan having a starting point and an ending point, wherein the first route plan is based on at least one parameter and wherein the first route plan is configured to cause the vehicle to generate an overpressure event; in response to receiving an operator input to change at least one operating parameter of the vehicle, generating a second route plan based, at least in part, on the operator input; displaying the first route plan and the second route plan on a display; and in response to receiving an operator input to select a route plan displayed on the display, generating actuator instructions to control the vehicle to follow the selected route plan.

In accordance with another embodiment, a non-transitory computer-readable medium is disclosed storing instructions that, when executed by a processor, cause the processor to perform a method for controlling a vehicle, the method comprises: generating a first route plan having a starting point and an ending point, wherein the first route plan is based on at least one parameter and wherein the first route plan is configured to cause the vehicle to generate an overpressure event; receiving an operator input to change at least one operating parameter of the vehicle; generating a second route plan based, at least in part, on the operator input; displaying the first route plan and the second route plan on a display; receiving an operator input to select a route plan displayed on the display; and generating actuator instructions to control the vehicle to follow the selected route plan.

Additional objects and advantages of the disclosed embodiments will be set forth in part in the description that follows, and in part will be apparent from the description, or may be learned by practice of the disclosed embodiments.

DETAILED DESCRIPTION

Various embodiments of the present disclosure relate generally to methods and systems for an automatic route planning (e.g., flight planning) of a vehicle and, more particularly, to methods and systems for an automatic route planning for supersonic flight of a vehicle.

In view of the restrictions discussed above, supersonic flight may present several challenges. As a first example, supersonic flight may be limited by certification authorities (e.g., FAA), such as minimum/floor requirements that dictate a minimum altitude that a vehicle may cruise at supersonic, maximum Mach speed requirements (based on altitude) for a geographic region, etc. As a second example, supersonic vehicles may need to plan a route in compliance with these requirements, especially with consideration of any sonic booms generated during flight and the effect of these sonic booms on the geographic region. Therefore, determining a route for a vehicle based on sonic booms and the geographic regions over which the vehicle travels may be a challenge.

The present disclosure is directed to overcoming one or more of the above challenges. In general, the present disclosure is directed to systems and methods for automatically planning a route of a vehicle. For instance, a system of the present disclosure may determine whether a supersonic operation and an associated boom footprint of the vehicle will occur over a target location, even if the supersonic operation and/or associated boom footprint are at an acceptable dB level at a few thousand feet over that target location; and, if so, perform an automatic route planning of the vehicle to meet maximum dBs limitations at a certain number of feet over specific target locations like population centers, national parks, or other desired areas. The automatic route planning may include obtaining flight plan clearance data or using a previously defined route; generating a route plan based on the clearance data; and generating actuator instructions to execute the route plan. Subsequently, the route plan may be displayed to an operator to inform the operator of the potential risks of following the route plan, e.g., the plan when displayed may show there will be supersonic operation of a vehicle over a target location (e.g., a location on the ground), so as to diminish sonic booms over a geographic location to comply with certification authorities. Furthermore, the system of the present disclosure may determine and display a route plan that avoids populated areas, supersonic flight restriction areas, and/or certain weather conditions, such that the vehicle operator may determine which corridors the vehicle may fly at the target altitude, so as to reduce sonic booms over populated areas, avoid areas where sonic booms are not allowed, and/or avoid detrimental weather conditions (as weather is a complication in already non-standard operating condition). Moreover, the system of the present disclosure may override a supersonic flight restriction, in response to a user input or based on a convergence analysis showing adjustments to route or altitude to allow operations over certain corridors with adjustments made in real time (e.g., operator or user inputs are immediately reflected in the display to allow quick and real-time visualization of any sonic booms impact and how that impact can be shifted to a less populated area). In addition, the system of the present disclosure allows visualization of how a change an altitude of the vehicle reduces sonic booms over areas of interest or concern (populated areas, areas where sonic booms are not allowed, undesirable weather conditions, restricted areas, etc.). Therefore, the systems and methods of the present disclosure may determine a route plan of a vehicle traveling at supersonic speeds while considering various criteria (e.g., corridors, population, weather, and/or supersonic flight restrictions).

While this disclosure describes the systems and methods with reference to aircraft, it should be appreciated that the present systems and methods may be applicable to management of vehicles in general, including automobiles, boats, drones, spacecraft, or any other autonomous or non-autonomous vehicles equipped with components capable of performing the techniques discussed herein.

FIG. 1is a block diagram of a flight management system (FMS) implemented in a vehicle, according to one or more embodiments. FMS110may assist in the generation of route plans for vehicles based on, e.g., sonic booms (overpressure events) resulting from data received. The data to generate the route plans may be received, at least in part, from an operator of the vehicle. As schematically depicted inFIG. 1, FMS110may include the following components or subsystems, each of which may assume the form of a single device or multiple interconnected devices: a controller architecture120, at least one vehicle display device130, computer-readable storage media or memory140, and an operator input interface150(e.g., a graphical user interface, analog interface, or any other operator input mechanism). FMS110may further contain sensor data sources160including, for example, an array of vehicle sensors providing, e.g., a speed of the vehicle, an altitude of the vehicle, and the like. FMS110may also contain a datalink subsystem170including an antenna172, which may wirelessly transmit data to and receive data from various sources external to FMS110, such as a cloud-based forecasting service of the type discussed herein.

Although schematically illustrated inFIG. 1as a single unit, the individual elements and components of FMS110can be implemented in a distributed manner utilizing any practical number of physically-distinct and operatively-interconnected pieces of hardware or equipment. When FMS110is utilized to construct supersonic route plans for a manned vehicle (i.e., a vehicle that carries an operator onboard), the various components of FMS110may typically all be located onboard vehicle100. Comparatively, in implementations in which FMS110is utilized to construct route plans for a remotely-controlled vehicle, e.g., an unmanned aerial vehicle (UAV), certain components of FMS110may be carried by the remotely-controlled vehicle100, while other components may be situated at the ground-based station or facility from which the remotely-controlled vehicle100is piloted. For example, in this latter instance, vehicle display device130, operator input interface150, and some portion of memory140may be located off board the remotely-controlled vehicle100. It will be understood, however, that any element illustrated inFIG. 1for displaying and/or calculating a display of a flight path based on a sonic boom may be contained onboard or off board vehicle100.

The term “controller architecture” may broadly encompass those components utilized to carry out or otherwise support the processing functionalities of FMS110. Accordingly, controller architecture120can encompass or may be associated with any number of individual processors, flight control computers, navigational equipment pieces, computer-readable memories (including or in addition to memory140), power supplies, storage devices, interface cards, and/or other suitable components. Controller architecture120may include or cooperate with any number of firmware and/or software programs (e.g., computer-readable instructions) for carrying-out the various process tasks, calculations, and control/display functions described herein. Controller architecture120may exchange data with one or more external sources to support operation of FMS110. In this case, bidirectional wireless data exchange may occur over a communications network, such as a public or private network implemented in accordance with Transmission Control Protocol/Internet Protocol architectures or other conventional protocol standards. Encryption and mutual authentication techniques may be applied, as appropriate, to ensure data security.

Memory140may include any number and/or type of storage media suitable for storing computer-readable code or instructions, as well as other data generally supporting the operation of FMS110. In certain embodiments, memory140may contain one or more databases, such as geographical (terrain), runway, navigational, and historical weather databases, which may be updated on a periodic or iterative basis to ensure data is up-to-date. The databases maintained in memory140may be shared by other systems onboard vehicle100, such as an Enhanced Ground Proximity Warning System (EGPWS) or a Runway Awareness and Advisory System (RAAS). Memory140may also store one or more values associated with sonic boom formation (e.g., an overpressure event). In at least some implementations of FMS110, one or more overpressure profiles specific to vehicle100, for example, a range of vehicle100types may be stored within memory140. Additional discussion of such vehicle-specific overpressure profiles are provided below.

Sensor data sources160may supply various types of data or measurements to controller architecture120during operation of vehicle100. Such data or measurements may include, but are not limited to, inertial reference system measurements, Flight Path Angle (FPA) measurements, airspeed data, groundspeed data, altitude data, attitude data including pitch data and roll measurements, yaw data, data related to vehicle100weight, time/date information, heading information, atmospheric conditions data, flight path data, flight track data, radar altitude data, geometric altitude data, wind speed and direction data, and fuel consumption data. Further, in certain embodiments of FMS110, controller architecture120and other components of FMS100may be included within or cooperate with any number and type of systems commonly deployed onboard vehicle100including, but not limited to, an Attitude Heading Reference System (AHRS), an Instrument Landing System (ILS), GNSS Landing System (GLS), and/or an Inertial Reference System (IRS).

With continued reference toFIG. 1, vehicle display device130(or vehicle display devices130) may include any number and type of image generating devices on which one or more avionic displays may be produced. When FMS110is utilized to construct route plans for a manned vehicle100, vehicle display device130may be affixed to a static structure of vehicle100as, for example, a Head Down Display (HDD) or Head Up Display (HUD), or Head Mounted Display (HMD) like a “Near-To-Eye” unit. Alternatively, vehicle display device130may assume the form of a movable display device, e.g., a pilot-worn display device, or a portable display device, such as an Electronic Flight Bag (EFB), a laptop, or a tablet computer carried into vehicle100by an operator. Similarly, when FMS110is utilized to construct route plans to pilot a remotely-controlled vehicle100, vehicle display device130may be realized as an HDD or HUD unit affixed to the static structure of a control facility, a portable electronic device carried into such a control facility by an operator, or a movable display device worn by an operator either while flying the vehicle or when remotely operating a remotely-controlled vehicle100.

At least one avionic display (e.g., an avionic display illustrated inFIG. 3) may be generated on vehicle display device130during operation of FMS100. The term “avionic display” may include, but may not be limited to, an aircraft-related display, and may display data in a textual, graphical, cartographical, or any other suitable format. The avionic display displayed on vehicle display device130may be generated to include various visual elements or graphics, which may be referenced by a pilot during the supersonic flight planning process. Such graphics may include, for example, textual readouts relating to route plan criteria or text annunciations indicating the revised or updated route plans generated by FMS110based on, e.g., an overpressure of vehicle100. The avionic display or displays generated by FMS110may include alphanumerical input displays of the type commonly presented on the screens of Multifunction Control and Display Units (MCDUs), Control Display Units (CDU), or Touch Screen Controllers (TSCs) for example. FMS110can also generate various other types of displays on which symbology, text annunciations, and other graphics pertaining to route planning and to the revised or updated route plan(s). For example, FMS110may generate graphics on one or more two-dimensional (2D) avionic displays, such as a horizontal or vertical navigation avionic display, a Primary Flight Display (PFD), or an exocentric three-dimensional (3D) avionic display. A method, which may be implemented by FMS110in performing processing tasks related to boom-regulated route planning, will now be described in conjunction withFIG. 2.

FIG. 2is a flowchart illustrating an exemplary method of automatically generating a revised route plan based on one or more operating parameters of a vehicle, according to one or more embodiments. Method200may be implemented by FMS100to improve route planning by calculating revised (e.g., alternative) route(s) for vehicle100, displaying the route(s) to the operator of vehicle100, and/or controlling vehicle100to follow the revised route(s). Method200may include a number of computer-implemented functions or process steps performed by a central processing unit e.g., central processing unit, as discussed below. These functions or steps are non-limiting, and additional steps may be performed. Further, certain steps may be omitted and/or the illustrated steps may be performed in different sequences than those shown inFIG. 2.

In Step202, an initial route plan may be generated. This route plan may be generated to include a start point (e.g., a first waypoint) and an end point (e.g., a second waypoint). The route plan may be separated into one or more segments. For example, multiple waypoints may be included along the route. These waypoints may be determined upon considering one or more factors that might impact the operation and/or navigation of vehicle100, such as a change in one or more parameters of vehicle100including, but not limited to, a speed, a heading, an altitude, or the like. The initial route plan may be generated based on information contained in memory140, information transmitted from a base station to vehicle100via antenna172, and/or a combination of both information obtained from the base station and information saved in memory140. Additionally, an operator may select one or more inputs, e.g., a destination, one or more targets to avoid (latitude/longitude and a radius around that latitude/longitude or a complex or asymmetrical boundary based on a city or a population center boundary data), or other data, via operator input interface150. Controller architecture120may generate the initial route plan using information from any one or more of these sources. Once plotted, the initial route plan may be displayed to the operator on vehicle display device130. For example, as shown inFIG. 3, the initial route plan may be displayed with multiple waypoints, as will be described below.

In Step204, an operator input may be received via operator input interface150. The operator input may be a change, or a desired change, to one or more operating parameters, such as one or more of a speed change, an altitude change, a heading change, etc. The operator input may be based on a desire to change a flight time, avoid a geographical area, avoid a weather pattern, etc. The operator input may change an effect of vehicle100. For example, increasing the speed of vehicle100may cause vehicle100to create an overpressure events at certain altitudes and ranges. This overpressure envelope and potential events (dB profiles at certain locations) may be undesirable in certain scenarios, e.g., if vehicle100is traveling over a city, a populated area, or other geographical area designated by a regulatory body. Therefore, data may be obtained from vehicle100, a cloud-based system, or a ground-based system storing population data indicating population density and/or distribution, and/or flight restrictions related to overpressure events. The operator may consider the obtained data in entering the operator input. Alternatively, or additionally, inputting the change, or desired change, may cause the route plan to change such that vehicle100may avoid or travel near but not through an undesirable weather event (e.g., a weather event that may be hazardous to vehicle100) but without resulting in an overpressure event occurring too close to an area of concern (population center, national parks, restricted areas, or other areas where overpressure events are undesirable).

In Step206, the revised route plan may be generated. It will be understood that the revised route plan may be generated regardless of whether the route plan is capable of being performed. For example, even in the event the revised route plan causes vehicle100to violate a regulation, travel near or through a undesirable weather event, or experience other undesirable event, the revised route plan may be generated and, in Step208, the revised route plan options may be displayed on vehicle display device130. In this manner, the operator may view the revised route plan options based on the change in parameter(s) to vehicle100and make an informed decision.

The operator may accept or decline the revised route plan options presented in Step210. For example, the revised route plan may violate one or more regulations (e.g., based on an overpressure event caused by vehicle100) or cause vehicle100to travel through a weather event, vehicle100may not carry enough fuel to complete the route based on the revised route plan, etc. In the event the revised route plan is not accepted by the operator in Step210(e.g., a response of “NO” via operator input interface150), the method loops back to Step204to receive operator input to again change one or more operating parameters of vehicle100. In this manner, the operator may view multiple revised route plans based on different parameter changes, and the operator may select the revised route plan that suits the needs or decisions of the operator. In some embodiments, only the original route plan and one of the revised route plans may be displayed at the same time. For example, no two revised route plans may be displayed at the same time.

In the event the revised route plan is accepted by the operator in Step210(e.g., a response of “YES” via operator input interface150), vehicle100may be controlled based on the revised route plan in Step212. For example, the revised route plan may include one or more different waypoints, segments, starting point, and/or ending point. Controller architecture120may control vehicle100, alone or in combination with one or more systems (e.g., a cloud-based system, a ground-based system, etc.), to travel along the revised route plan. The revised route plan may violate one or more regulations, cause vehicle100to travel through a weather event, or cause other undesirable scenario. The operator may be capable of selecting the revised flight path based on information provided via FMS110, information received from a ground-based station, and/or from a cloud-based system via antenna172, as well as information or knowledge known to the operator. For example, a regulation may have changed and the computer systems may not have been updated. In this scenario, the operator may travel over a geographical location that the revised route plan indicates as unnavigable, but which the operator knows to be navigable. Alternatively, or additionally, vehicle100may experience mechanical complications, may be low on fuel, or individuals onboard vehicle100may need assistance that requires the route plan to be revised. In these scenarios, it may be necessary to violate one or more regulations and/or travel through one or more weather events due to an emergency.

FIG. 3illustrates route plans generated on a vehicle display device, according to one or more embodiments. For instance, a vehicle display device130shown inFIG. 1may generate an original route plan and/or a revised route plan, as will be discussed in detail below. While not visually depicted inFIG. 1andFIG. 3, vehicle display device130may include one or more input devices, such as a graphical user interface, one or more analog input devices, or the like. Additionally, vehicle display device130may receive inputs from operator input interface150, which may include one or more of the graphical user interface and/or analog input devices. As shown inFIG. 3, multiple route plans may be displayed at once. These route plans may be identified by a legend, such as the legend in the upper right corner of vehicle display device130, which identifies graphics associated with an original route plan (“ORIGINAL”) and graphics associated with a revised route plan (“R”), as will be described herein. FMS110may further generate other graphics to aid the operator in deciding whether to select a revised route as the new route plan. For example, vehicle display device130may generate a 2D or 3D map with vehicle heading markers. The route plans may be superimposed over the map view presented. It will be understood that other perspectives are possible (e.g., a forward looking, three dimensional perspective). The route plans may be distinguished utilizing distinctive waypoint markers as shown inFIG. 3. If desired, other graphics may be provided on the map view, including, for example, a graphic of vehicle100, a heading, a range ring graphic, and various symbols indicative of terrain, weather, and structures (not shown inFIG. 3for clarity).

In one embodiment, an original route plan300may be illustrated by the solid line. Original route plan300may be divided into multiple segments, with waypoints identified by the squares. An overpressure event302that is predicted to occur based on parameters associated with original route plan300may be identified by the U-shaped member. In the example ofFIG. 3, overpressure event302may occur in the third and last segment of original route plan300based on parameters of vehicle100in the last segment. A location320may be identified by the “X” on the screen, but may be identified by any other symbol and/or text. Location320may be a geographical location, e.g., a city, over which an overpressure event is not allowed by regulation. Based on the current trajectory of original route plan300, overpressure event302may be predicted to occur at location320, which may be undesirable.

The operator may change one or more parameters of vehicle100via operator input interface150. For example, the operator may wish to determine whether changing a heading of vehicle100will avoid an overpressure event above location320. After receiving the operator input, a revised route plan304may be generated on vehicle display device130. Revised route plan304may be identified by the dashed line, and may include multiple segments separated by waypoints having a “+” shape. It will be understood that the waypoint(s) and/or segment(s) may be identified by any symbol(s). In this example, revised route plan304illustrates that the parameters input by the operator may also create an overpressure event306. Yet, overpressure event306is shifted from overpressure event302, such that overpressure event306does not occur over location320. The operator may determine whether revised route plan304is a desired route plan. If yes, then the operator may select revised route plan304as the new route, as described herein with reference to Steps210and212inFIG. 2.

FIG. 4is a flow chart illustrating an exemplary method of automatically generating a plurality of revised route plans based on one or more operating parameters of a vehicle, according to one or more embodiments. Method400may be implemented by FMS100to improve route planning by calculating revised (e.g., alternative) route(s) for vehicle100, displaying the route(s) to the operator of vehicle100, and/or by controlling vehicle100to follow the revised route(s). Method400may include a number of computer-implemented functions or process steps performed by a central processing unit e.g., central processing unit, as discussed below. These functions or steps are non-limiting, and additional steps may be performed. Further, certain steps may be omitted and/or the illustrated steps may be performed in different sequences than those shown inFIG. 4. Method400may include certain steps that are similar to the steps in method200. For those steps of method400that are similar, reference will be made to the corresponding step in method200.

In Step402, an initial route plan may be generated. This route plan may be generated in a manner similar to that described with reference to Step202of method200.

In Step404, an operator input may be received via operator input interface150. The operator input may be received in a manner similar to that described in reference to Step204of method200. Additionally, the operator may change multiple parameters and/or may change a single parameter multiple times such that multiple revised route plans may be generated. A prompt may be given to the operator to select parameters for each of a first revised route plan, a second revised route plan, and so on, until all desired parameter changes are input by the operator.

In Step406, the multiple revised route plans may be generated. It will be understood that the revised route plans may be generated regardless of whether the route plans are capable of being performed. For example, even in the event the revised route plans cause vehicle100to violate a regulation, travel through a weather event, or experience other undesirable event, the revised route plans may be generated and, in Step408, each of the revised route plans may be displayed on vehicle display device130. In this manner, the operator may view each of the revised route plans based on the selected changes in parameters to vehicle100.

In Step410, the operator may select one of the multiple revised route plans. Alternatively, the operator may determine that none of the revised route plans are desirable, and may select the original route plan. Selection of the desired route plan may be made via vehicle display device130, operator input interface150, or any other input mechanism.

After the desired route plan is selected, vehicle100may be controlled based on the route plan selected in Step410. Vehicle100may be controlled in Step412in a similar manner as described with respect to Step212in method200.

FIG. 5illustrates route plans generated on a vehicle display device, according to one or more embodiments. For instance, a vehicle display device130shown inFIG. 1may generate an original route plan and/or revised route plans, as will be discussed in detail below. While not visually depicted inFIG. 1andFIG. 5, vehicle display device130may include one or more input devices, such as a graphical user interface, one or more analog input devices, or the like. Additionally, vehicle display device130may receive inputs from operator input interface150, which may include one or more of the graphical user interface and/or analog input devices. Similar to the embodiment ofFIG. 3, multiple route plans may be displayed at once in the embodiment shown inFIG. 5. These route plans may be identified by a legend, such as the legend in the upper right corner of vehicle display device130, which identifies graphics associated with an original route plan (“ORIGINAL”), graphics associated with a first revised route plan (“R1”), and graphics associated with a second revised route plan (“R2”), as will be described herein. FMS110may further generate other graphics to aid the operator in deciding whether to select a revised route as the new route plan. Depending on the route, weather conditions, and other factors, any number greater than two alternate routes could be presented limited only by the ability to display the options to the operator. For example, vehicle display device130may generate a 2D or 3D map with vehicle heading markers. The route plans may be superimposed over the map view presented. It will be understood that other perspectives are possible (e.g., a forward looking, three dimensional perspective). The route plans may be distinguished utilizing distinctive waypoint markers as shown inFIG. 5. If desired, other graphics may be provided on the map view, including, for example, a graphic of vehicle100, a heading, a range ring graphic, and various symbols indicative of terrain, weather, different atmospheric conditions that affect overpressure propagation through the atmosphere and structures (not shown inFIG. 5for clarity).

In one embodiment, an original route plan500may be illustrated by the solid line. Original route plan500may be divided into multiple segments, with waypoints identified by the squares. An overpressure event502that is predicted to occur based on parameters associated with original route plan500may be identified by the U-shaped member. In the example ofFIG. 5, overpressure event502may occur in the third and last segment of original route plan500based on parameters of vehicle100in the last segment. A location520may be identified by the “X” on the screen, but may be identified by any other symbol and/or text. Location520may be a geographical location, e.g., a city, over which an overpressure event is not allowed by regulation or desired by the operator. Based on the current trajectory of original route plan500, overpressure event502may be predicted to occur at location520, which may be undesirable.

The operator may change parameters of vehicle100via operator input interface150. For example, the operator may wish to determine whether changing a heading, a speed, or the like of vehicle100will avoid an overpressure event above, or within a certain range of location520as defined by the operator, location520. After receiving the operator input, a first revised route plan504may be generated on vehicle display device130. First revised route plan504may be identified by the dashed line, and may include multiple segments separated by waypoints having a “+” shape. It will be understood that the waypoint(s) and/or segment(s) may be identified by any symbol(s) or colors. In this example, first revised route plan504illustrates that the parameters input by the operator may also create an overpressure event506. Via the display shown inFIG. 5, the operator will be able to tell that overpressure event506will also likely occur over location520.

A second revised route plan508may be generated on vehicle display device130based on a second set of parameters altered and input by the operator. Second revised route plan508may be identified by the long-short-long dashed line, and may include multiple segments separated by waypoints having a “*” shape. It will be understood that the waypoint(s) and/or segment(s) may be identified by any symbol(s) or colors. In this example, second revised route plan508illustrates that the parameters input by the operator may also create an overpressure event510. Yet, overpressure event510is shifted from overpressure events502and506, indicating overpressure event510will likely not occur over location520. The operator may determine whether revised route plan508is a desired route plan. If yes, then the operator may select revised route plan508as the new route, as described herein with reference to Step410inFIG. 4. Alternatively, as described herein, the operator may select any route plan shown on vehicle display device130.

Further, a computer may be configured to execute techniques described herein. Specifically, the computer (or platform as it may not be a single physical computer infrastructure) may include a data communication interface for packet data communication. The platform may also include a central processing unit (“CPU”), in the form of one or more processors, for executing program instructions. The platform may include an internal communication bus, and the platform may also include a program storage and/or a data storage for various data files to be processed and/or communicated by the platform such as ROM and RAM, although the platform may receive programming and data via network communications. The platform also may include input and output ports to connect with input and output devices such as keyboards, mice, touchscreens, monitors, displays, etc. The various system functions may be implemented in a distributed fashion on a number of similar platforms, to distribute the processing load. Alternatively, the systems may be implemented by appropriate programming of one computer hardware platform.

As used herein, the terms “comprises,” “comprising,” “having,” including,” or other variations thereof, are intended to cover a non-exclusive inclusion such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements, but may include other elements not expressly listed or inherent to such a process, method, article, or apparatus. In this disclosure, relative terms, such as, for example, “about,” “substantially,” “generally,” and “approximately” are used to indicate a possible variation of ±10% in a stated value. The term “exemplary” is used in the sense of “example” rather than “ideal.” As used herein, the singular forms “a,” “an,” and “the” include plural reference unless the context dictates otherwise.