KR20030004307A - A layered subsystem architecture for a flight management system - Google Patents

Abstract

Residing on the computing platform 21 and based on a layered subsystem architecture including an operator interface subsystem 100, a communication subsystem 200, a flight management subsystem 300, and a database management subsystem 400. Improved Aircraft Flight Management System (FMS), where the architecture is predicted by enforcing a subsystem dependency law that allows a given subsystem to be dependent only on other subsystems in the same or lower hierarchy .

Description

A LAYERED SUBSYSTEM ARCHITECTURE FOR A FLIGHT MANAGEMENT SYSTEM

Existing flight management systems (FMSs) have been very difficult to modify or maintain. The FMS development program, which must strictly reuse the code from the existing FMS development program, required a long development period that was difficult to adopt and an excessively high cost. In addition, when a plurality of FMS development programs are simultaneously executed using an existing FMS development program, two or more development teams performing similar development tasks are less likely to use each other's work. This long development period, excessive development costs and lack of team synergy are problems due to the poorly documented and easily scalable software architecture of existing FMS development programs.

Since little or no software architecture has been developed and documented for multi-system management in FMS, the modifications required to implement the new FMS requirements are made by each software developer. The requirements of the software used as the basis of the software implementation often occur that do not reflect the original problem or the added original capability that has already been solved. The result is a software solution that is virtually unrecognizable from the user's point of view.

Over time, changes can be repeated, resulting in a software module that is related to each other but not manageable as a result of such software implementation. When this situation occurs, the result can be a "spaghetti-code". To complicate matters further, several FMS programs can run simultaneously. As such, a code-based development process is used, it is practically impossible to take advantage of the desired changes made in other FMS development programs that are currently in progress. As a result, the workforce of more than one program team cannot work together to solve the same problem at the same time.

There was a need to improve a flight management system (FMS) architecture that is compatible with a variety of flight-related equipment on a variety of aircraft types. Such an improved FMS architecture forms the basis for a collection or product line of related FMS systems that includes functionality common to all aircraft types, or also includes specific aircraft specific features such as C-5 freighters.

The present invention generally relates to a flight management system. More specifically, the present invention provides a full-featured flight management system that extends a single architecture to a variety of subsystems (eg, communications, controllers, monitoring, and data links, etc.) that are independently managed and difficult to integrate in normal circumstances. It is about.

1 shows the basic configuration of an FMS and the environment surrounding it.

2 shows a block diagram of a subsystem related to FMS and related dependencies.

FIG. 3 illustrates additional dependencies including the subsystem from FIG. 2.

4 illustrates a hierarchical structure of the subsystem shown in FIG.

FIG. 5 shows a block diagram using arrows to illustrate conceptual dependencies between the five avionics subsystems included in the overall flight management subsystem.

FIG. 6 shows a block diagram for explaining the subsystem dependency law for the flight management subsystem shown in FIG. 5.

Figure 7 shows the hierarchical structure of the decomposed FMS.

8 shows the complete subsystem hierarchical structure of the overall FMS architecture and associated subsystems, and their interdependencies.

The present invention is directed to an improved FMS architecture that provides the basis for an FMS product line. Each FMS in this product line is common to all aircraft types, or includes features specific to special aircraft, such as C-5 freighters.

One aspect of the present invention relates to an FMS layered 'subsystem' architecture that enables various subsystems at an associated layered architecture level to interface with each other based on predefined dependencies for all FMS.

Another aspect of the invention relates to a method for controlling and coordinating communication between various subsystems in an FMS. The law of the first FMS architecture is that each subsystem operation reflects a real-world problem that has already been solved, such as a leg transition. The law of the second FMS architecture reflects a mirror related to the real world interdependencies within which the subsystem interdependencies are defined by a particular aircraft operation. Such laws are verified during implementation and / or execution of software associated with each of each FMS subsystem.

Preferably, the automatic function of the FMS of the present invention is to provide an additional high level of functionality which the crew routinely performs during flight, and which is not possible for the crew to perform manually under normal conditions. The improved FMS of the present invention is hierarchically organized in a layered subsystem architecture and includes software residing on the computing platform. The FMS subsystem inside the layered architecture of the present invention includes the following.

(a) An operating interface subsystem that provides a simple and easy understanding of the interface between the crew and the aircraft, collects FMS input from the crew, and provides the crew with FMS output. The subsystem provides a coordination service (application function) that allows the crew to collect information directly from the aircraft sensors and to manipulate the aircraft's equipment directly.

(b) a communications subsystem that manages and interprets communications with aircraft and coordinates the on-board equipment used for communications;

(c) Flight management subsystems that maintain the electronic flight plan and provide the functions associated with complex flight actions that guide the flight of the aircraft.

(d) Database management subsystems that provide various databases and associated information and control access to them.

The novel features of the present invention can be clearly and easily practiced by those skilled in the art by the following detailed description of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS In the drawings appended to the present invention, like reference numerals designate the same or functionally similar elements in all the drawings, and constitute a part of the detailed description of the specification and describe the features of the present invention together with the detailed description. Is shown.

The present invention relates to an improved flight management system (FMS) 11 comprising a software architecture composed of layered subsystems. The purpose of developing the FMS layered subsystem architecture of the present invention is to document the rules of implementation and dependencies required for the development and modification of the software of the individual subsystems contained throughout the FMS.

The layered subsystem architecture of the present invention can be used in a family or product line of related FMS systems for various aircraft types. The novel and advanced FMS product line of the present invention is based on a three-dimensional, domain-based software architecture, with each independent FMS software checked against that architecture. Since there is no guidance on the architecture to follow in order to implement software, current systems are implemented in a special way using means to perform work in the fastest way possible. By reflecting real world dependencies in the construction of the FMS product line system, most spaghetti code phenomena can be prevented.

The flight management system (FMS) of the present invention is a complex integrated system that automates the work of many flight crews routinely performed during flight. Because of the speed and performance of the FMS, many high-level tasks are made possible by the FMS that cannot be done manually by the flight crew. The internal operation of the FMS system is complex, but from the crew's point of view it is very simple. For the crew, the FMS system is a system that is equipped with a single interface with most avionics systems in an aircraft, or an electronic version of a flight plan. The biggest obstacle in constructing FMS, especially in relation to humans, is to continue to implement the increased complexity inherent in a scene while preserving the simplicity perceived by the crew.

The work performed by the flight management system is numerous and generally complex. The improved FMS architecture provided by the present invention provides a user with a complex but simple and easily understood system architecture.

The FMS architecture is described in terms of functionally oriented subsystems from the end user's perspective. It is very important that the implementation of the system is consistent with the conceptual view of the architecture, but that does not mean that its implementation must follow a functional decomposition approach. However, the concepts and laws added by the implementation and architecture that can be chosen faithfully support the resulting implementation.

The first step in designing the architecture of an FMS is to define the problem to be solved and to test the system's operation. 1 conceptually illustrates the FMS 11 and its environment. Although the diagram shows a simple situation of the whole system, it is not unrealistic to think of it that way. After all, the FMS 11 is the interface between the crew 12 and the aircraft 13. Basically, using the interface provided by the FMS 11, the operator 12 initiates the service provided by the FMS 11. Depending on the service disclosed, the FMS 11 obtains information from the aircraft's sensors 14 and coordinates the aircraft's avionics 15. In addition, the data may use the interface device 16 to load data to or retrieve data from the FMS 11.

Although the FMS 11 is shown simply in a conceptual diagram, substantially complex tasks are performed by the FMS 11. Therefore, in order to understand the specific way in which the FMS 11 performs its function, the contents of the FMS box shown in FIG. 1 should be reviewed. In order to describe the function of the FMS 101, its operation is divided into several groups called subsystems. The subsystems generally depend on other subsystems to perform their work. Finally, the overall FMS 11 corresponds to a computing platform 21 that performs its function, as shown in FIG.

The configuration of the layered subsystem architecture included in the FMS 11 is shown in FIG. At this architecture level, the functionality of the FMS 11 is classified in the broadest sense. Thus, internally there are four major subsystems that interact to perform all the sets of performance provided by the FMS 11.

The operator interface subsystem 100 collects input from the crew operator 12 and provides output to the crew operator 12. Such configuration is accomplished by several devices, such as a control display unit (CDU), an electronic flight equipment system (EFIS), and various call displays.

The communication subsystem 200 manages and interprets equipment used for communication with the aircraft 13 and for communications including voice and data transmission. The interpretation of the data link information provided by the communications management unit (CMU) (not shown) is performed by this subsystem.

The flight management subsystem 300 manages all functions related to the flight of the aircraft 13, including, for example, flight planning and aircraft guidance.

The database management subsystem 400 manages and provides access to several databases mounted on the entire FMS, the best known of which is the worldwide navigation database (not shown).

In FIG. 2, the diagram shows each subsystem in a box, their dependencies between each other are indicated by arrows, and the boxes surrounding the computing platform 21 are shown. In FIG. 2, the dependency on the computing platform 21 or the external environment is not shown. However, it is clear that dependencies exist physically and conceptually. Conceptually, the FMS internal subsystems 100, 200, 300, and 400 are more dependent on the internal environment than the computing platform 21. Physically, internal subsystems 100, 200, 300, and 400 depend on computing platform 21 to access the external environment. This is because the computing platform 21 has a physical dependency on aircraft wiring that affects the external aircraft subsystem.

FIG. 3 shows not only the dependencies illustrated in FIG. 2, but also additional dependencies between the respective subsystems in the computing platform 21. Note that additional equipment management subsystem 500 has been added. The purpose of the equipment management subsystem 500 is to provide an area level interface to external equipment on which the performance of the application functions contained in the other subsystems 100, 200, 300, and 400 is based. For example, flight management subsystem 300 is dependent on input from an external inertial navigation system (INS) (not shown). Logically, the area level interface to the INS is important to the flight management subsystem 300, while the low-level interface is not. Therefore, the equipment management subsystem 500 implements an area level interface to the INS using the low-level interface device included in the computing platform service subsystem 600. The equipment management subsystem 500 also shows that it has a dependency on the computing platform service subsystem 600. Communication subsystem 200 illustrates that it has dependencies on database management 400, equipment management 500, and computing platform service 600 subsystems.

An important aspect of the hierarchical subsystem architecture is shown in FIG. 3. Note that the dependencies between the subsystems are shown in the "down" direction. The subsystem only depends on inputs from other subsystems in the same or lower hierarchical layer. The lower subsystem has no dependencies with that of the upper layer. Thus, the architecture is carried out by a principle known as the "subsystem dependent law". The subsystem dependency rule is that a given subsystem depends only on other subsystems that are at the same or lower hierarchy. The “same layer” of this law is not shown in FIG. 3, but this is clearly shown in the illustration of the system to which the present invention follows. This law means that higher level subsystems may depend on lower level subsystems to perform their functions, but not vice versa. The implementation of this dependency establishes a client-server structure in which the client is always valid for the parent server. This architectural feature makes it possible to ensure that the server is designed so that the client is mostly irrelevant. It is very important to maintain the integrity of the system architecture that the subsystem dependency law is observed in all subsystems of the system.

The importance of obeying the subsystem dependency law is illustrated in another example. Ideally, all application functions included in the various subsystems in the FMS are not dependent on the operator interface subsystem 100. Thus, the operator interface subsystem 100 is implemented as the best client at the top of the hierarchical architecture, while the rest of the application functionality is included in the subsystem at the lower layer of the hierarchy. By adhering to the subsystem dependency law, there is no dependency between the subsystem and the operator interface subsystem 100. Therefore, the introduction of a new type of operator interface subsystem required by a particular aircraft type, as expected, has no effect on the underlying FMS subsystem.

With some modification to the diagram, the architecture looks a bit different. In FIG. 4, the same subsystem shown in FIG. 3 is shown, but their dependencies are different. That is the only difference between the two, except for the obvious differences in the drawings. However, such differences are important to provide the basis for system development. The subsystem hierarchy diagram of FIG. 4 illustrates all potential dependencies present in the system. This point of the present system has the advantage of providing implicit guidance for design decisions of development and future system upgrade periods due to subsystem dependency laws. By using the subsystem hierarchy diagram of FIG. 4, it can be demonstrated that the dependency is valid in the hierarchy diagram of FIG. 2. If dependencies become invalid, the question arises whether the overall system representation is correct, whether the behavior of the system is well understood, and whether the subsystem diagrams represent potential dependencies. It is important that subsystem diagrams be maintained at the real world domain level. By keeping the subsystem diagram at that level, it should be clear what the set of valid potential dependencies actually is. And since domain language is used, when consulting with domain experts, such as navigation equipment technicians, about the validity of dependencies, the diagram can be interpreted and understood by FMS system structural experts and domain experts.

Although the top level subsystem diagram of FIG. 1 illustrates a potential dependency between the FMS and the external environment, its level is too high to adequately address the performance of all sets typically provided by the FMS. As long as the subsystem dependency rules are followed, further decomposition of each of the major FMS subsystems is valid. Disassembly of each major subsystem further refines the functionality of the subsystem and clarifies potential internal dependencies. For example, further decomposition into the subsystem may be performed if the diagram obtained thereby provides a reasonable level of understanding. Each subsystem must be defined using a domain language. For illustrative purposes, the flight management subsystem 300 is further disassembled, for example, and the results are shown in FIG. 5.

In FIG. 5, the conceptual dependencies between the five subsystems representing real world aircraft flight operations are shown to be included in the disassembled flight management subsystem 300, according to the present invention. In this regard in decomposition, the focus is to determine how the performance of the overall FMS 11 is degraded and what the relationship between the performances is. To determine the appropriate disassembly, the purpose of the FMS is to simply automate many of the operations traditionally performed by the flight crew 12. Therefore, the operation is performed automatically by the resulting FMS design. In addition, it is important to use domain language whenever possible during system development to enable domain experts to easily assess the accuracy of the system. In FIG. 5, the flight guidance subsystem 310 shows a dependency on the flight engineering 320, navigation 330, and flight planning 340 subsystems. On the other hand, navigation radio tuning subsystem 350 has a dependency on flight plan 340 and navigation 330 subsystem.

In developing the decomposition shown in Figure 5, no attention has been given to the structure of the dependencies. On the other hand, it is strictly implemented in terms of "what actually happened in the real world." However, if the operation is simply rearranged in the diagram, it becomes clear that the real world city of the system follows the subsystem dependency law already described. A schematic diagram of a disassembled flight management subsystem 300 is shown in FIG. 6. The simple fact that subsystem-dependent laws have been applied to the design provides confidence that the model is accurate.

Of course, as with the overall FMS system, the hierarchical diagram of the disassembled flight management subsystem 100 of FIG. 6 may be shown as a subsystem hierarchical diagram. The hierarchical subsystem configuration of the disaggregated flight management subsystem 100 is integrated with respect to the entire FMS to become a hierarchical diagram of the subsystem to more specifically understand the internal dependencies in the overall FMS.

Referring to FIG. 7, the complex hierarchical subsystem diagram shows the effect of separating the flight management system 100 into subsystems 310, 320, 330, 340, 350 on the overall FMS system architecture. Similar decomposition can be performed on other major subsystems to bring out the complete subsystem for the entire FMS 11. It is very important to recognize that the subsystems in the architecture cannot be carved into the stone. As FMS evolves, it is only natural that subsystems change. However, the architecture should always reflect the area-level language and potential dependencies that reflect the realistic view of the FMS 11. The structure of the hierarchical subsystem of the overall FMS 11 is shown in FIG. It should be noted that the architecture of the entire hierarchical subsystem shows each of the other major subsystems in isolation. Indeed, further analysis of the FMS subsystem finds that there are still other kinds of functions that serve as 'automated crew' which must be performed. Therefore, referring to FIG. 8, an automated crew role subsystem 360 is added to the FMS in accordance with the present invention. The fact that the automated crew role subsystem 360 has been added by the post-design review of the FMS shows that the location and number of both layered subsystems and subsystems included in each floor are flexible during development. As the design of the FMS product line proceeds, the location and number of both layered layers and subsystems included in each layer will be fixed. However, further improvements will be made during the initial FMS development for some of the first specific aircraft types.

Each subsystem of one representative FMS 11 implementing the present invention in the planned FMS product line is described below. The description below includes the purpose of the subsystem (at a very high level), the relationship between that subsystem and the rest of the subsystems included in the FMS, and the design concepts and architecture principles of that subsystem. Each subsystem may be described in broad terms with respect to input, output, and processing as part of that subsystem.

The sole task of the operator interface subsystem 100 is to manage all air crew 12 interfaces to the FMS. This mainly includes a control display unit (CDU) and an electronic flight instrument system (EFIS). However, the crew member 12 may include any other device or system that can be used to influence the operation of the FMS. This may seem insignificant, but there are only two parts to operator interface management that collect and interpret input from the crew 12 and collect, initialize and display system information for output to the crew 12. have. This may affect the architecture of the FMS because it is important that the operator does not focus on the details related to the basic operation. For example, when a flight attendant makes an input to the FMS requiring some operation to be performed, the operator interface subsystem 100 only knows what application functions are present to support the operation and the required operating parameters. Just do it. In the output from the FMS 11, the operator interface subsystem 100 recognizes that an application function provides data for display to the flight crew 12. However, it is not included in the important manipulation of the data.

As shown in FIG. 8, the operator interface subsystem is preferably separated into a CDU management subsystem and an EFIS management subsystem. Because of the complex data entry method used by the typical CDU, the more complex of the two subsystems included in the operator interface subsystem 100 is the CDU management subsystem 110. The typical CDU has a general purpose interface that includes a keyboard and several buttons. Here, the functional meaning of each button can be changed depending on the operating environment, such as communication radio tuning. This general purpose interface, which involves so many possible combinations of entries, contrasts with a special purpose interface such as a cockpit switch or dial with a limited number of possible inputs. Since data entry and error handling by the air crew 12 must be performed in a special operating environment, the overall nature of the resulting CDU interface brings the complexity of the CDU management subsystem 110.

Although the general purpose nature of the typical CDU makes it difficult to manage, its flexibility makes the typical CDU a very attractive human-machine interface to the crew 12. Furthermore, the architecture of the present invention allows the overall operation of the FMS 11 to be changed without making any changes to the basic application in the FMS. Because of this, the interface to the basic application included in the various subsystems within the FMS architecture must be well defined, and the application itself should never directly quote the operator interface subsystem 100.

The CDU management subsystem 110 may be based on a "CDU page". A CDU page is a series of information displayed simultaneously on the display surface of the CDU. In general, the relevant information appears on the CDU page such that there is a series of displayed parameters and a series of options associated therewith to define the operation that the series of buttons on the CDU bezel will perform. When an operation is performed via the bezel button, the operation generally requires a typed-in entry where the contents of the CDU scratchpad are used to transfer data. The basic concept of this CDU operation should be provided to every page defined within the system as a general purpose service and thus form the basic structure for the management of the CDU pages.

Finally, there should not be any other FMS subsystem related to the CDU as an input / output device. The CDU management subsystem 110 contained within the operator interface subsystem 100 interprets CDU inputs and is solely responsible for translating the inputs into internal data representations and commands for application functions contained within other FMS subsystems. Has In other words, the CDU management subsystem 110 is responsible for making service requests for application functions included in other FMS subsystems and for converting the resulting internal data representation into an appropriate format for display on the CDU display.

The input portion of the CDU management subsystem 110 provides the following functions.

(a) The data collection function collects the inputs of the various air crew 12 into the CDU, such as pressing a bezel button and entering a stretch pad.

(b) The data verification function compares the input of the crew member 12 against a predicted input format based on the CDU operating environment, and executes an error-handling routine on request.

(c) The data interpretation function translates the input of the air crew 12 into a specific service request based on the CDU operating environment and provides the service request to the appropriate application in the FMS.

In general, the CDU management subsystem 110 only interprets the input of the air crew 12 at the time when the input of the air crew 12 is properly transmitted to other FMS subsystems. For example, the CDU management system 110 converts text-based input for latitudes such as "N35.12.45" into appropriate internal numerical representations such as "+35.2125". In this case, the CDU management subsystem 110 or, optionally, the operator interface subsystem 100 knows that a latitude entry is expected to be entered, thereby knowing that it needs to recognize the format of a valid latitude entry. Knowing this information, the operator interface subsystem 100 can determine the validity of the entry and convert the entry in human readable form (string) into an internal FMS representation of latitude. This level of data processing can be accommodated in the operator interface subsystem 100 as needed. In general, it makes no sense for other FMS subsystems that contain application functions, such as flight trajectory determination, to convert strings into an internal form for display. Once the entry is verified, the operator interface subsystem 100 will determine which operation is being requested and will perform the requested application function. In contrast, the CDU management subsystem 110 is not responsible for converting the distance between two latitude / longitude pairs and sending the result to the application subsystem. Instead, the FMS includes an area service subsystem 610 that has two latitude / longitude pairs as input and includes an application function to calculate the distance between them. The CDU management subsystem 110 is only allowed access to the input provided by the CDU.

The operator interface subsystem 100 is responsible for collecting and formatting FMS calculation data from other FMS subsystems and displaying the data so that the crew 12 can understand it. For example, the CDU management subsystem 110 (or any other portion of the operator interface system 100) does not handle the direction and speed of the aircraft determining wind speed and direction. For example, the 'calculate wind' application function within the navigation subsystem 330 determines wind parameters in whatever way is best considered, and the operator interface subsystem 100 simply recalls the wind parameters and returns the application. Just use it for an interface. Once the data is retrieved again, the operator interface subsystem 100 is responsible for converting the internal representation to, for example, a string for display on the CDU.

It may be appropriate for the operator interface subsystem 100 to perform more complex processing. For example, another FMS subsystem may internally indicate all headings toward the aircraft's true north. However, the operator interface may provide an option to indicate the progress direction based on true north or magnetic north. In this case, true north / magnetic north conversion is appropriately performed by the operator interface (in addition to maintaining the current magnetic north / true north selection trajectory). It is dangerous to limit this process to what is required for display purposes only. There should be few moments dealing only with data that has not been processed for general display purposes.

The EFIS management subsystem 120 collects various data from other FMS subsystems for display on the EFIS. The data is then converted into the format required by the EFIS in the FMS internal representation and then transmitted to the EFIS. A typical EFIS can have several modes of command. Sometimes the FMS may be an entry that instructs the EFIS to be in the proper mode, but there may be several ways for the crew to select the desired EFIS mode. For example, there may be a control panel switch interpreted by the FMS. Or there may be a CDU page to select the EFIS mode. Regardless of how it applies, the EFIS subsystem must provide a service that can be used to select the EFIS mode. This service can be used to make changes on the EFIS display at the request of another subsystem (or possibly the same subsystem). Importantly, the EFIS management subsystem 120 should not simply depend on other FMS subsystems to determine the EFIS mode. It may further be that they are to be transmitted by some other FMS subsystem to the EFIS management subsystem 120. Output processing of the EFIS management subsystem can be simple. Basically, low level FMS subsystems may include application functions used to collect FMS data, such as flight direction steering bars. The data can then be reformatted as required for transmission and reception with the EFIS. Finally, the services of the device management subsystem 510 can be used to send data to the EFIS.

In view of the overall operation of the FMS, the data link management subsystem 210 may not be anything more than a remote user using the FMS application functionality. Remote user inputs and outputs are sent to the aircraft via wireless transmission instead of an integrated connection to the devices in the cockpit. However, in detail, it does not exclude the view of the data link subsystem 210 in terms of CDU management or EFIS management. Just like the CDU management subsystem 802, the subsystem is aware of the presence of a CDU; The data link management subsystem 210 is the only FMS subsystem that recognizes the existence of a data link. The data link management subsystem 210 interprets the message from the data link and translates the message into a service request for an application function included in another FMS subsystem. However, no other FMS subsystem knows the origin of this data request. They are simply obtained from the CDU management subsystem 110. Isolation of data link services is an important point in the design and construction of FMS production lines.

Although no other entry in the FMS needs to know the data link, the FMS subsystem that resides above the data link management subsystem 210 clearly knows its existence and can use its knowledge as requested. In general, the crew 12 is not aware of any automatic changes, such as changes in flight plans. Since the air crew 12 is ultimately responsible for the safe operation of the aircraft 13, a final statement relating to any command affecting the flight trajectory should be made. Therefore, upon receiving the uplink, the crew 12 must manually accept the change. Since this can be done by a CDU, the CDU management subsystem 110 must access the data link management subsystem 210 to gather the appropriate information. It is important to remember that these details of the data link management subsystem 210 should be provided, which may be important to the upper subsystem. For example, it is appropriate to provide a service that can indicate whether the uplink is in progress and also indicate the type of data to be uplinked. It is not appropriate to provide services that interpret raw message data or communicate with external data link computers.

Continuing to describe a data link as a remote user using real world terminology, the user present at the other end of the data link is probably human. In the CDU management subsystem 110, data may be transformed into and understood from a user understandable form, such as a string. Even if the remote user on the other end of the data link is a human, in the context of FMS it can also be a machine. Nevertheless, the data link management subsystem 210 acts similar to the CDU management subsystem 110 with the user's point of view. The data link subsystem 803 may also transform the data into a form understood by the user, and may transform the data from this form, but in this case the user may be a machine.

From the structural point of view of the data link management subsystem 210, the bottom line may actually appear as two subsystems in the operator interface layer. All these details regarding the physical interface can be handled internally by the subsystem. The operation requested for a data link should be internally transformed into a series of applied service requests required to perform that operation. Therefore, exactly the same apply service request is made when the same operation is commanded over the data link as commanded over the CDU.

Input processing required for the data link management subsystem 210 includes collection of transmission requests (uplink or downlink) from the data link device and collection of uplink data from the data link device. The collected data is then used to implement applicable services to fulfill the appropriate request. Additionally, this subsystem receives a request from the CDU management subsystem 110 or input from a higher subsystem in an FMS, such as operator mode setting from the operator interface subsystem 100.

The output of the data link management subsystem 210 includes the main message of the data link device. Data that is downlinked is first received from an application function in another FMS subsystem, then formatted and transmitted to the data link device using device management subsystem 510.

Flight management subsystem 300 is generally responsible for performing all operations of the system that handles the actual flight of aircraft 13. This operation is typically performed by a crew, but now refers to a function that is automated by the FMS 11 or a new function to assist the crew in carrying out the work. Not surprisingly, the general basic functions performed by the FMS 11 are almost one-to-one with the crew of a normal aircraft. Thus, flight management subsystem 300 may be broken down into the following subsystems.

a) The pilot defines the control inputs that guide the aircraft along the desired route. This corresponds to a guidance subsystem 310.

b) The flight engineer monitors the performance of the aircraft and predicts the status of the aircraft along the flight path. This corresponds to a flight engineering subsystem 320.

c) The navigator defines the current location and aircraft status. This corresponds to navigation subsystem 330.

The fact that the FMS has an associated function of two extraneous sets of data requires the presence of an automated crew subsystem 360. This form of functionality is appropriately illustrated using example embodiments that do not limit the scope of the rights.

The FMS provides the crew operator 12 the ability to manage a set of custom waypoints physically provided in the database subsystem 400. The aircraft operator 12 may define an on-demand ground point through input of a ground point name and ground point location. The operator may also modify or delete some of the on-demand grounds. Once defined by the operator, the on-demand ground point can only be used as any other entity that defines the location included as one of the end points of the flight plan section.

Suppose you entered a flight plan and one of the segments is defined using a custom ground point. The operator then decides to delete the on-demand ground point from the database. However, FMS system requirements do not allow this if the custom ground point to be deleted is part of a flight plan. This requirement would violate the subsystem dependency rule if implemented simply by having the database management subsystem 400 check flight plans through the on-demand ground point process. However, the analysis of these requirements reveals that this is a higher level system requirement. The system is clearly defined to effect such an operation. Certainly, there is no problem in deleting the custom ground point at any time in the custom ground point process. Thus, a suitable way to implement this requirement may be to add an on-demand "destroy point" application function within the automated crew subsystem 360 above the database management and flight planning subsystems 400,340.

This is a specific example in the scheme of the overall FMS structure. However, it also has additional capabilities that fall into the general category. Indeed, the autotuning function for navigation radio may be classified as an application function within the automation crew subsystem 360. It utilizes the services of navigation, flight planning, and database management subsystems 330, 340, and 400 to realize more complex higher level functions. Navigation tuning subsystem 350 appears as a separate subsystem because of its importance and complexity as a feature of the overall FMS.

The inputs to this subsystem actually vary. The most important aspect in the input for this subsystem 801 is that the input is from two or more subsystems. If a capability of this subsystem requires input from only one subsystem, that capability should be run in that subsystem whenever possible.

As with these inputs, the output of this subsystem depends on a wide variety of high-level functions that are executed.

In legacy systems that are available, this subsystem does not exist virtually. Indeed, the absence of this subsystem may be one of the main reasons for the complexity of execution in that system. In the example of an on-demand ground point given above, the legacy FMS system actually performed the equivalent function by simply subordinate the database management function to the flight planning function. The increase and complexity of artificial dependency by the number of higher-level functional forms implemented in a typical FMS is virtually incomprehensible.

An approach for the development of the automated crew subsystem 360 is to identify the functions that belong to a group of higher level functions within an existing system. Once identified, it may simply be a matter of moving that function from where it is currently executed to the automated crew subsystem 360. By moving the function, the artificial dependency from the original subsystem can be removed.

The navigation radio tuning subsystem 350 may have two general functions. Firstly, the subsystem can generally provide a set of services for tuning the navigation radio receiver on each board to a selected radio navigation aid located at a predetermined geographical location. Secondly, the subsystem provides an optimized series of radio navigation aids in which the receiver is tuned. By using the functions of the two navigation radio tuning subsystems 350, the navigation subsystem 330 can calculate the position of the aircraft very accurately. By performing this function in an automated form, the navigation radio tuning subsystem 350 and navigation subsystem 330 together serve to mitigate radio navigation assistance determination and radio tuning tasks from the air crew 12.

The series of radio tuning services provided from the navigation radio tuning subsystem 350 is designed for use by other FMS subsystems requesting to tune the navigation radio. It is natural to ask, "Why can't the pilot tune the navigation radio directly and provide this set of services directly?" The answer is that navigation radio is useful, and it must be tuned to navigation aids whose location is known on Earth. If the navigation radio is only tuned to frequency, the resulting information is useless. Therefore, the set of services provided by the navigation radio tuning subsystem 350 is only present to determine the radio navigation aid (more specifically the location of the navigation aid) related to the desired tuning operation. Of course, the radio may be tuned using the navigation aid identifier, in which case the operation may be easy. However, only when tuning via frequency, the service will look for a series of navigational aids that exist geographically near the current aircraft position for navigational aids having a given frequency. If there is no comparable navigation aid nearby, the radio will continue to tune but the navigation information as a result received from the radio will generally be useless in determining the location of the radio.

The navigation radio tuning subsystem 350 also provides the ability to automatically select specific navigational aids to which the radio is tuned and consequently calculate the optimal position. The automatic tuning function is designed to be executed without the intervention of the crew 12.

Each time you manually tune the navigation radio through the input provided by the higher subsystem, the navigation radio subsystem 350 attempts to correlate its tuning request with the radio navigation assistant at a location geographically close to the current aircraft location. I try. The radio navigation aid geographic location information is collected from a database management subsystem 400. When the autotuning function is activated, the navigation radio tuning subsystem 350 periodically searches for a better set of navigation aids for which the navigation radio is to be tuned. The input required for the autotuning function includes the navigation aid list of the navigation database 403 and the current aircraft position of the navigation subsystem. The accuracy of the aircraft position provided to the navigation radio tuning subsystem determines whether the subsystem selects aeronautical assistance for optimal aircraft position calculation.

The output of the navigation radio tuning subsystem 350 is a simple radio tuning command that proceeds to the navigation radio implemented by the device management subsystem 510. It is important in the FMS design that other subsystems cannot directly tune the navigation radio of the device management subsystem 510.

Both existing military and commercial FMS systems have navigational radio tuning. Commercial aircraft generally have a VHF omnidirection radio (VOR) receiver and scanning measuring equipment (DME). Military aircraft typically have a VOR receiver and a tactical air navigation (TACAN) transmitter.

Vertical induction subsystem 312 has another high-level functionality of the FMS. The purpose is to provide an instruction for the aircraft 13 to maintain the planned vertical course. Such instructions may be in the form of rising / falling signals or control surface deflection. Regardless of the output form, the details of the vertical induction do not appear to the user of the subsystem.

Since some specific aircraft do not use the functionality contained in the vertical guidance subsystem 312, it is desirable that the vertical guidance subsystem 312 can be separated from the FMS with minor functional collisions with the rest of the system. . This separation is expected to affect the flight engineering subsystem 320. Therefore, it may be allowed to separate the aeronautical engineering 320 and vertical guidance 312 subsystems together.

The vertical guidance subsystem 312 is designed to simply calculate a steering command based on the altitude-related information for each section of the aircraft flight plan. There is no knowledge of complex structures and patterns that can be used in the construction of flight plans.

The vertical guidance subsystem 312 collects the planned vertical trajectory of the aircraft from the flight planning subsystem 340 and the current aircraft status vector from the navigation subsystem, respectively. The aeronautical engineering subsystem 320 will provide specific data that serves to limit the operation of the vertical guidance subsystem 312. The vertical induction subsystem 312 may be responsible for collecting constraints such as the maximum elevation altitude from the aviation engineering subsystem 320.

The initial output of the vertical guidance subsystem 312 is a set of instructions that cause the aircraft 13 to follow the planned vertical trajectory. Vertical guidance subsystem 312 provides instructions in the form of speed and altitude targets or in the form of pitch instructions, as desired for a particular aircraft autopilot. The vertical guidance subsystem 312 is preferably capable of generating both forms for reuse in various aircraft types. In addition, the vertical induction function 312 will output a command to drive autothrottle when installed in the main aircraft.

Lateral guidance subsystem 311 has another set of high level functionality of the FMS. The purpose is to provide a command for the aircraft to maintain the planned lateral course. The command may be in the form of a left / right signal or control plane displacement. Regardless of this output form, the details of the lateral guidance do not appear to the user of the subsystem.

The lateral guidance subsystem 311 should be designed to simply require a flight planning section regardless of its source. The lateral guidance subsystem 311 is exactly the same as a section that has a complex structure, such as standard instrument departure (SID), standard terminal arrival (STAR), or holding pattern. Manually formed sections should be processed. The lateral guidance subsystem 311 requires only the variables of the current segment and the next two segments in the flight plan. The lateral guidance subsystem 311 obtains the navigation data directly from the navigation subsystem 330 and computes an instruction to follow the planned lateral route.

The lateral guidance subsystem 311 collects the aircraft's planned lateral trajectory from the flight planning subsystem 340 and the current aircraft status vector from the navigation subsystem 330, respectively. The aeronautical engineering subsystem 320 may provide specific data that serves to limit the operation of the lateral guidance subsystem 311. Lateral guidance subsystem 311 may be responsible for collecting constraints, such as maximum bank angle, from aeronautical engineering subsystem 320. The initial output of the lateral guidance subsystem 311 is a set of instructions, such as a roll instruction, which causes the aircraft 13 to follow the planned lateral trajectory.

The aviation engineering subsystem 320 automates many of the functions typically performed by aircraft crew members known in the past as 'airline engineers'.

(a) The weight and balance function monitors and calculates the total weight and center of gravity (CG) of the actual and predicted aircraft 13.

(b) The V-speed function calculates aircraft performance flight speeds, such as minimum output flight speed, based on current conditions.

(c) The flight information function calculates and predicts various variables such as estimated time of arrival (ETA), fuel consumption and fuel balance at each point in the flight plan.

The aeronautical engineering subsystem 320 resides in one of the top tiers hierarchically within the FMS architecture and performs its tasks using the services of the subsystems that reside hierarchically lower tiers.

In aeronautical engineering subsystem 320, most of the algorithms used by the various functions are the same regardless of the type of aircraft on which the algorithm is performed. The aeronautical engineering subsystem 320 is designed to load aircraft specific data, such as variables used to calculate the distance required for takeoff, into an internal database. The aeronautical engineering subsystem 320 may collect data obtained from the performance database 402 by accessing the services provided by the database management subsystem 400.

Due to the variety of work performed by the aeronautical engineering subsystem 320, the inputs to this subsystem vary widely. Many functions typically require variables provided by the operator. Typical inputs include values such as gross weight, zero fuel weight and external ambient temperature. This kind of input is used to perform operations such as calculating takeoff and landing data (TOLD) variables. Complex functions, such as the calculation of peak points, performed in the aviation engineering subsystem, require knowledge of flight planning and the current state of the aircraft. The aeronautical engineering subsystem 320 collects these inputs from the lower layer subsystem of the required FMS. The performance database 402 provides the inputs generally required in the aeronautical engineering subsystem 320.

Two kinds of output are provided by the aeronautical engineering subsystem 320. The first kind includes the calculation results available in higher subsystems such as TOLD. The second category includes calculation results that are inserted into the flight plan, such as the calculation of ETA, at all remaining waypoints. This result is inserted into the flight plan using the services of the flight plan subsystem 340.

Aircraft navigation may simply be described in the same sentence "where is the current position?" As opposed to the aircraft induction described in the sentence "where is the destination?" This simple sentence is the whole purpose of the navigation subsystem 330. Using the available navigation sensors, navigation subsystem 330 determines the three-dimensional geographic position and the 'aircraft state vector' which includes the aircraft lateral and angular positions. The aircraft state vector includes a basic set of variables such as aircraft position, altitude, heading, path, flight speed, ground speed, wind, vertical speed, attitude, attitude rates, and magnetic change. . These aircraft state vectors are formed in all other FMS subsystems and their associated functions in accordance with subsystem dependent laws.

For each amount of data in the navigation subsystem 330, there may be several possible units of measure. For example, the location may be provided in degrees / minutes / seconds, such as global latitude and longitude, or in radians or headings provided on a true north or magnetic north basis. The entire FMS design philosophy is to provide internal data in a single measurement system, such as metric, and to provide conversion routines that can be used in other units, such as dissociation (nm).

The navigation subsystem 330 can generate aircraft status vectors using several different navigation solutions. The actual solution provided for a particular aircraft depends on the suite of navigation sensors installed on that aircraft. The sensor bath may include devices such as navigation radios, inertial navigation systems (INS) and satellite positioning systems (GPS). Regardless of the type of sensor used to determine the aircraft state vector, the navigation subsystem 330 must provide the basic parameters listed above. The navigation subsystem 330 may use complementary sensors to assist sensors that do not provide full of variables. Moreover, the navigation subsystem 330 refines the raw sensor output using a blending or filtering algorithm. Regardless of the method used, navigation subsystem 330 is configured such that other FMS subsystems cannot see the computational method used to determine the aircraft state vector.

One function of the navigation subsystem 330 may be to determine which navigation sensor is used to generate the aircraft status vector based on the selection of the aircraft crew 12. The aircraft crew 12 may deselect the navigation sensor via the operator interface subsystem 100. Navigation subsystem 330 determines the sensor or combination of sensors that will provide the most accurate aircraft status vector.

In normal operation, the navigation subsystem 330 generates aircraft status vectors based on a set of manually or automatically selected navigation sensors. The aircraft state vector can be occupied by operations such as using acquiring data obtained directly from sensors such as GPS receivers or bearing information and ranges obtained from TACAN.

At a minimum, the navigation subsystem will provide aircraft status vectors using GPS, INS and navigation radios (using one or more navigation aids). Such aircraft status vectors can be derived by mixing information from two or more navigation sensors.

In simulated aircraft operation of the aircraft flight simulator, the navigation subsystem 330 generates aircraft state vector variables based on simulation instructions. When the navigation subsystem 330 occupies an aircraft state vector, it may assist as a navigation interface to other FMS subsystems that reside hierarchically the same or higher layers within the FMS architecture.

The function of flight planning subsystem 340 is responsible for creating and maintaining a segment list that defines an aircraft flight plan. A flight plan may consist essentially of three part-departures, destinations and one or more flight plan sections in between. The flight plan section is defined as the path between two ground points. Segments can be entered simply into flight plans by specifying ground points. In addition, segments of complex, predefined sequences, such as SID, STAR, and airborne routes, can be entered into a flight plan using a single input or a set of definition criteria. The flight plan and the manner in which the various types of flight plan sections are drawn up are designated as engineering standards distributed by ARINC. Special military flight patterns, such as air refueling and airdropping, that are not specified by the ARINC standard, can be standardized in the FMS product line.

Aircraft flight plans may be critical to aircraft operations, and several FMS subsystems may request access to the flight plans. It is important that a single copy consistent with the flight plan be maintained for all users of this data. Thus, other subsystems within the FMS requesting access to the flight plan should only use these services provided by the flight plan subsystem 340. In order to prevent possible contention between flight planning subsystem 340 clients, requests for flight planning modifications are prioritized and queued.

One function of the flight planning subsystem 340 is to handle incoming requests that add or delete flight segments or change information related to existing segments. Such requests may come from a variety of sources, including external sources such as aircraft crew 12 and datalink operators, and from other FMS subsystems. These requests are distributed in a standardized and consistent manner by the flight plan subsystem 340 regardless of the source. The distribution of any particular request is the same whether it is caused by a crew member or by another FMS subsystem such as flight engineering subsystem 320.

Flight planning subsystem 340 has the ability to allow other FMS subsystems to access information from the flight plan. All other subsystems within the FMS should use flight planning subsystem 340 to obtain flight planning data. When any element of the segment data is changed, the flight plan subsystem 340 instructs the other FMS subsystem that the flight plan has changed so that the change must be accepted or deleted.

In the FMS system according to the prior art, the functions equivalent to the flight planning subsystem 340 and the aircraft guidance subsystem 310 are tightly combined, which is complicated and time-consuming without the need for flight plan-related changes. Advantageously, in the layered subsystem architecture of the present invention, the aircraft guidance subsystem 310 is subordinate to the flight planning subsystem 340, and the flight planning subsystem 340 is at a higher layer, thus the aircraft guidance subsystem. Have no knowledge of (310). While the purpose of flight planning subsystem 340 is to maintain a list of flight plans, the purpose of aircraft guidance subsystem 310 is to guide aircraft flight trajectories. This disciplined separation results in an improvement in flight planning subsystem 340 to be much simpler and less time consuming than changes made in conventional FMS systems. Indeed, if the separation of these areas is strictly fixed, future changes in either the flight plan 340 or aircraft guidance 310 subsystem should be minimized.

Improvements to anticipated flight plans include additional special flight patterns, such as the military air refueling and air fall patterns described above. For many of these special patterns, it is desirable to have new functionality in the automated crew subsystem 360 having knowledge of the entire FMS. Adding new functionality to the automation crew subsystem 360 does not affect other core FMS subsystems. This minimizes side effects and the required regression testing.

The navigation database subsystem 403 is primarily responsible for managing the worldwide navigation database. Generally, when referring to a 'database' with respect to aircraft operations, the reference is actually made in a worldwide navigation database. There are several other databases that are important to the overall functionality of the FMS. Such databases include communication database subsystem 401 and performance database subsystem 402. The communication database subsystem 401 has the ability to access a frequency list primarily used in communication radio tuning. The performance database subsystem 402 has the ability to access information about the characteristics of the aircraft and the engine for a particular aircraft.

The navigation database subsystem 403 is responsible for retrieving data from the worldwide navigation database of the required type. The navigation database management subsystem should be able to retrieve a list of single entities and associated inputs obtained from the database. For example, a function may be provided for retrieving information related to a single navigation aid. Other functions may be provided for retrieving a list of navigational aids within 50 nautical miles at a given location. As another example, the requested entity may normally be in the form of a list, such as having multiple ground points in the case of a route. The key to successful development of the navigation database subsystem 403 is the construction of a relative standard interface that targets domain requirements. The implementation of these interfaces can be easily diversified based on database source data and does not affect other parts of the system. In general, the navigation database subsystem 403 will include navigation aids, SIDs, STARs, predetermined ground points, routes, airports, runways, military training routes (MTRs) and refueling routes.

The input process required by the navigation database subsystem 403 is simply the interpretation of the database request and the retrieval of corresponding data from the internal data structure. The output process of the navigation database subsystem 403 is simply to provide the requested data.

The performance database subsystem 402 is responsible for retrieving data from the requested performance database. This performance database subsystem 402 may be characterized by a general set of data required by the functionality of the flight engineing subsystem 320. The format and structure of the actual performance data will be hidden by standard interfaces available in other FMS subsystems. Like the navigation database subsystem 403, the key to successful development of the performance database subsystem 402 may be the construction of a standard interface that targets domain requirements. The implementation of these interfaces can be easily diversified with database source data and does not affect other parts of the system. The performance database subsystem 402 will have the ability to retrieve gas characteristics such as drag, V velocity (values and limits), altitude limits and lift coefficients. In addition, the performance database subsystem 402 will have the ability to retrieve engine characteristics such as thrust to power settings and fuel to power settings.

The input process associated with the performance database subsystem 402 is the interpretation of database requests and the retrieval of data from internal data structures associated with the request. The output process of the performance database subsystem 402 is generally to provide the requested data.

The communication database subsystem 401 is responsible for retrieving data from the requested communication database. The communication database subsystem 401 first has a frequency list used in the communication radio tuning process. This database is somewhat different from a performance or navigation database in that other FMS subsystems can both interpret and write to a communications database.

The input process required by this subsystem includes retrieving communication data for another FMS subsystem and storing communication data from the other FMS subsystem into its database structure. The output process of this subsystem is to send the requested data from the higher layer subsystem.

The computing platform service subsystem 600 has a subsystem that depends in some way on that computing platform. Subsystems within the compute platform service subsystem exist such that the true application of the FMS product line is completely separate from the underlying computing platform. Thus, sub-subsystems within the compute platform service subsystem should be implemented such that the interface between the subsystems remains unchanged even if they are modified to accommodate a particular compute platform.

Device management subsystem 500 includes all types of external devices, such as radios, navigation sensors, aircraft coordination devices, and CDUs, which interface with the FMS. All communication with the external device is to be managed using the services provided by the device management subsystem 500.

FMS's top priority in device management is to provide a standard interface to standard piece devices. The virtual device interface subsystem 510 includes the services typically provided by this type of device and the interface is considered to be part of the core FMS product line. The implementation of the virtual interface is based on a physical device that is a real part of the system.

Services provided by standard interfaces worth discussing-there are other features of the required services versus the optional services. Since the philosophy of the core FMS product line is literally reused, it requires some data to be available. This requires the concept of a standard interface in a standard device. The fact that the standard interface provides a service suitable for that type of device does not mean that all such types of device actually provide such a service. For example, there may be an INS that does not provide magnetic variation even when considering typical services of the INS. Given an INS that does not provide a rate of change, the core FMS product line will provide a calculated rate of change as a standard service. Therefore, there are two kinds of services provided by the standard interface—services required and optional services. When a standard interface is implemented, for a particular project, there are services that must run within the standard interface and other services that are not running. Each standard interface will list the required and optional services. The determination of whether a service is required or selected can be made simply based on whether it is used by the core product line.

It is important to note that the interface on a standard device is generally the logical model of the device. Thus, the virtual device interface subsystem 510 will specify the high level services associated with the device, as well as the services provided by the device. One example of such additional functionality occurs within the VOR receiver interface. In general, a physical VOR receiver is tuned by simply providing a frequency. Another ideal VOR of the model includes the identifier and the location of the navigation aid to which the radio is tuned and may use range and bearing information retuned from the receiver to determine the aircraft position. Thus, a service for tuning a VOR receiver in a standard interface includes frequency and location and identifier.

Each service provided by the standard interface contains an indication of the validity of the signal as well as the data to be transmitted. This may be particularly important in services that provide data from external devices to the FMS product line. For example, an air data computer (ADC) can provide an actual air speed to an application. In addition to providing the airspeed value, the ADC interface should provide an indication of the effectiveness of the airspeed. Its validity is based on criteria such as data freshness, the state of the physical device and the conditions of the physical interface.

There are two features relating to the input process within device management subsystem 500, which corresponds to the input received at the higher subsystem and the input received from the interfaced device. In the former case, data is generally intended for output to the interfaced device. Since this subsystem has a logical model of interfaced devices, each input provided from another FMS subsystem becomes the output of the device. In the latter case, the input data is collected from the interfaced device and can be used for access via the logical interface provided to each device.

Like the input process, the output process has two characteristics. The feature is the opposite of the two features of the input process. The output data is sent to the requested interface device. As mentioned above, the fact that data can be used in other FMS subsystems is a different way of expressing that the data is the output of this subsystem.

Redundancy management subsystem 520 provides backup contingency in the event that the process in charge of the FMS system fails. The FMS product line operates in the form of active / standby (hot spare), in which one processor is activated to perform the functions of the system while the other process is listening to the standby. If necessary, the waiting processor will take over the workload of the activating processor. The waiting processor is preparing to listen by periodic transmission of data from the activating processor so that it can take over and execute the task for the activating processor. The activation / standby mode assumes that the required data transfer can occur and that the aircraft is wired so that the processors can exchange roles.

Redundancy management subsystem 520 displays processor status to determine whether the activation processor is suitable for continuing its role. It also collects the data needed to influence the reversal of the processor role and prepares it for transmission to the waiting processor.

In addition to the data transfer, the redundant management subsystem 520 outputs an indication as to whether the processor has changed roles. The invention has the advantage of having both philosophies on hot spares and various FMS programs for special aircraft types.

Domain service subsystem 610 provides a set of common type definitions and primitive utilities used throughout the FMS product line system. Specifically, the definitions provided by the area service subsystem 610 relate to the area in which the system operates. It is important to understand that the entities exported from this subsystem are not simply a collection of software data types that facilitate the implementation of the system. Rather, this subsystem provides services provided in the application area. Examples of elements in the area service subsystem 610 include utilities for calculating longitude and latitude, distances between two points on Earth, defined as software data formats, and utilities for converting each value between radians and degrees. There may be. All other subsystems within the FMS system are expected to utilize the functionality provided by the area service subsystem 610 rather than defining itself. These subsystems do not include anything that depends on platform or aircraft. In this manner, the client system can be prevented from being dependent on the aircraft and the platform. The area service subsystem 610 accepts input variables such as bearing, distance, and longitude / latitude, and performs the requested process on those variables. However, none of those processes generate values that will reside in this subsystem. The output of the area service subsystem 610 is a definition in software format, which is commonly available in the FMS product line area and is a value calculated from the utility. The calculated output does not reside in this subsystem, but is simply returned to the client using it.

Operating system service subsystem 620 may buffer the remaining FMS subsystems from the host computing environment such that the core FMS is not dependent on any particular host or platform.

For example, the input to operational service subsystem 620 may be an Ada tasking model for the FMS system. This model translates into a platform model of the platform that can be subordinate to Ada Task. The output of the operational service subsystem 620 may be a condition indication that is the result of self-diagnosis of the host computing environment. Later, the FMS uses the condition indication as a component of the indication of other conditions such as data bus communication status.

The above-described embodiments and examples are provided so as to best describe the present invention and its practical application examples and to enable those skilled in the art to make and use the present invention. However, one skilled in the art will understand that the above detailed description and examples are provided by way of example only. Other modifications and variations of the present invention will be apparent to those skilled in the art, and the appended claims are intended to cover such modifications and variations. The detailed description set forth above is not intended to limit or limit the scope of the present invention. Many modifications and variations are possible in light of the above teachings without departing from the spirit and scope of the following claims. The use of the present invention is contemplated to include components having other features in a range that follows the principles of the layered subsystem architecture of the flight management system. It is intended that the scope of the invention be limited by the claims appended hereto.

Claims (29)

In a flight management system (FMS) architecture residing on a computing platform, where a given subsystem is predicted by enforcing a subsystem dependency law that depends only on other subsystems in the same or a sub-system: An operator interface subsystem for receiving input from an operator and providing output to the operator; A communication subsystem for managing and interpreting communication between aircraft and equipment used for communication; A flight management subsystem for managing functions associated with the operation of the aircraft; And A database management subsystem for managing and providing access to a plurality of databases mounted in the FMS architecture. 2. The system of claim 1, wherein application functions in the communication, flight management, and database are independent of an operator interface subsystem. 3. The system of claim 2, wherein the operator interface subsystem is implemented as a client in the top portion of the hierarchy, and other application functions are in the bottom portion of the hierarchy. The system of claim 1, wherein the application subsystem and the operator interface subsystem are independent of each other, thereby allowing the introduction of a new type of operator interface without affecting the underlying application. The system of claim 1, wherein the subsystem is dependent on the computing platform to access an external environment. The system of claim 1, wherein the subsystem is dependent on the computing platform to access an external environment because the computing platform has a physical dependency on aircraft wiring and affects an external system. 10. The system of claim 1, wherein the device management subsystem provides an area level interface to equipment that is based on the performance of application functions. The system of claim 1, wherein the device management subsystem implements a high level interface using lower level equipment provided by the computing platform. The system of claim 1, wherein the equipment management subsystem has a dependency on the computing platform. 2. The system of claim 1, wherein the communication subsystem has dependencies on the database management subsystem, equipment management subsystem, and computing platform services. The system of claim 1, wherein the communication subsystem has voice and data transfer capability. The system of claim 1, wherein database access to the database management subsystem is provided for flight planning and aircraft guidance information. In a flight management system (FMS) that automates operations performed by flight crew members during flight, and provides high-level operations that would normally not be possible by manual crew mission performance: Architecture with electronic flight plan; And An operator service module allowing an operator using the crew interface to initiate the services provided by the FMS, Wherein the architecture implements a combination of flight operations including Standard Instrument Departure (SID), Standard Terminal Arrival (STA), air route, air refueling, and air fall, The architecture consists of a hierarchical subsystem hierarchy, which is based on the subsystem dependency law, such that a given subsystem depends only on other subsystems in the same or lower hierarchy, and also The architecture communicates with a flight crew interface, Dependent on the disclosed service, the FMS can, if appropriate, obtain information from aircraft sensors and take control of aircraft electronics. A method of controlling and coordinating communication between various modules in a flight management system (FMS) composed of a layered subsystem hierarchy architecture, Coordinating communication between operating subsystems integrated in the FMS based on subsystem dependency laws that allow certain subsystems to be dependent only on other subsystems in the same or lower layer layers; And Verifying the communication based on the subsystem dependency law during implementation and execution of software associated with the module. 15. The method of claim 14, wherein the module behavior is continually checked for a law that ensures that module behavior reflects module dependencies through FMS mirroring, which is a real world dependency defined by the FMS subsystem dependency law. How to. A flight management system (FMS) that includes a layered subsystem architecture in a computing platform and is predicted by enforcing subsystem dependency laws that allow a given subsystem to depend only on other subsystems in the same or lower hierarchical layers. Wherein the FMS architecture is: An operator interface subsystem for receiving input from an operator and delivering output to the operator; A communication subsystem for managing and interpreting communication with aircraft and equipment used for communication; A flight management subsystem that manages operations associated with the operation of the aircraft; And And a database management subsystem for managing and providing access to a plurality of databases embedded in the FMS architecture. 17. The system of claim 16, wherein the communication, flight management, and database management subsystems further comprise a plurality of application operations, each independent of an operator interface subsystem. 18. The system of claim 17, wherein the operator interface subsystem is implemented as a client in a normal portion of the hierarchy when the communication, flight management, and database subsystems are in a lower portion of the hierarchy. . 17. The communication, flight management, and database management subsystem of claim 16, wherein the communication, flight management, and database management subsystems are independent of the operator interface subsystem, thereby introducing a new type of operator interface to the communication, flight management, and database subsystems. A system which allows for introduction without. 17. The system of claim 16, wherein the operator interface, communication, flight management, and database management subsystems are dependent on the computing platform to access an external environment. 17. The system of claim 16, wherein the computing platform has a physical dependency on aircraft wiring to affect a plurality of aircraft systems. 17. The system of claim 16, further comprising an equipment management subsystem that provides an area level interface to a plurality of equipment based on the performance of application functions in the operator interface, communication, flight management, and database management subsystems. system. 17. The system of claim 16, further comprising an equipment management subsystem that implements a high level interface using a plurality of lower level devices provided by the computing platform. 17. The system of claim 16, further comprising an equipment management subsystem dependent on the computing platform. 17. The system of claim 16, further comprising the compute platform service subsystem. 26. The system of claim 25, wherein the communication subsystem is dependent on the database management subsystem, equipment management subsystem, and computing platform service subsystem. 17. The system of claim 16, wherein the communication subsystem has voice and data transfer capability. The system of claim 16, wherein the navigation subsystem is: A flight planning subsystem for creating and maintaining a list of segments defining flight plans; And And an aircraft guidance subsystem for calculating steering commands and target points to guide the aircraft flight trajectory. 29. The system of claim 28, wherein database access from the database management subsystem is provided to the flight planning and aircraft guidance subsystem.