Patent Description:
Many vehicles include multiple systems to perform various functions. Frequently, the various systems use navigational state information to perform their respective functions. The various vehicle systems may acquire the navigational state information using a navigation system architecture, where the navigation system architecture derives a vehicle state in a reference frame of interest. The vehicle state elements may include parameters like rotation rates, body accelerations, attitudes, headings, angles, velocities, and positions. Document <CIT> discloses a navigation or motion tracking system including components associated with particular sensors, which are decoupled from a tracking component that takes advantage of information in the sensor measurements. The architecture of this system enables development of sensor-specific components independently of the tracking component, and enables sensors and their associated components to be added or removed without having to re-implement the tracking component. Document <CIT> discloses an adaptive navigation system for airborne, ground and dismount applications. The system performs adaptive fusion of all sensed signals, information sources, and databases that may be available on a single or multiple cooperative platforms to provide optimal Positioning, Navigation, and Timing (PNT) state. Document <CIT> discloses a sensor system, having sensor elements for sensing at least to some extent different primary measured variables or use different measurement principles. A signal processing device evaluates the sensor signals from the sensor elements at least to some extent collectively and rates the information quality of the sensor signals. The signal processing device further provides a piece of information about the consistency of at least one datum of a physical variable. Document <CIT> discloses a method for providing integrity for a hybrid navigation system using a Kalman filter. The method includes determining a main navigation solution for one or more of roll, pitch, platform heading, or true heading for the vehicle using signals from a plurality of GNSS satellites and inertial measurements. Solution separation is used to determine a plurality of sub-solutions for the main navigation solution.

Systems and methods for fault detection, exclusion, isolation, and re-configuration of navigation sensors using an abstraction layer are provided. In certain embodiments, a system includes a plurality of sensors that provide redundant sensor measurements, wherein redundancy of the redundant sensor measurements is achieved based on an independence between measurements from different physical sensor units in the plurality of sensors. The system includes a fusion function configured to receive the redundant sensor measurements from each sensor in the plurality of sensors and calculate fused navigation parameters. Further, the system includes an abstraction layer that calculates an estimated state based on the fused navigation parameters, wherein the estimated state comprises the fused navigation parameters and safety assessment information for the fused navigation parameters. Moreover, the system includes a plurality of user systems, wherein each user system in the plurality of user systems is configured to receive the estimated state from the abstraction layer.

Drawings accompany this description and depict only some embodiments associated with the scope of the appended claims. Thus, the described and depicted embodiments should not be considered limiting in scope. The accompanying drawings and specification describe the exemplary embodiments and features thereof, with additional specificity and detail, in which:.

Under common practice, the various described features are not drawn to scale but are drawn to emphasize specific features relevant to the example embodiments.

The following detailed description refers to the accompanying drawings that form a part of the present description, which shows, through illustration, specific illustrative embodiments. However, it is to be understood that other embodiments may be used and that logical, mechanical, and electrical changes may be made.

Methods and systems described in the present disclosure provide for fault detection, isolation, exclusion, and re-configuration of navigation sensors using a fusion function and an abstraction layer. In particular, systems described herein use a combination of a fusion function and an abstraction layer between sensors and user systems, where a user system is a system that uses navigation parameters provided by the sensors or navigation parameters derived from the data from the sensors. The abstraction layer allows the sensors to operate without understanding the properties of the user systems. Likewise, the abstraction layer allows the user systems to operate without understanding the properties of the sensors. The abstraction layer may communicate an estimated state for the navigating vehicle directly to the user systems. As used herein, the estimated state for the navigating vehicle refers to parameters derived from measurements by the sensors, where the parameters describe an aspect of navigation for the vehicle. For example, the estimated state may describe rotation rates, acceleration, attitudes, headings, velocities, positions, altitudes, air data, and other data relative to the navigation of a vehicle. The estimated state may also include safety measures of the parameters derived from sensor measurements, which safety measures are described below in greater detail.

When a user system receives the estimated state for a navigating vehicle, the user system may directly determine operational limits from the received estimated state. For example, the user system may determine the operational limits by ascertaining whether the estimated state meets defined operational requirements for an operation. Thus, the abstraction layer allows the user system to operate without determining sensor availability including whether sensors are faulty.

<FIG> is a block diagram illustrating a typical prior art system <NUM> having user systems <NUM> that directly acquire sensor measurements from the sensors <NUM>. A sensor <NUM> may be a device that provides data representing different aspects of the navigation state of the system <NUM>. For example, a sensor <NUM> may be an inertial measurement unit, a global navigation satellite system receiver, an altimeter, a magnetometer, a barometer, a thermometer, or other devices that can provide information related to the navigational state of the system <NUM>. The system <NUM> may also include multiple of the same sensor <NUM>. For example, the system <NUM> may include multiple inertial measurement units to increase the redundancy of the measurements provided by the sensors <NUM>. The system <NUM> may also include multiple sensors <NUM> that provide the same information. For example, the system <NUM> may include different sensors <NUM> that redundantly provide inertial measurements using different mechanisms.

In <FIG>, the user systems <NUM> may be sub-systems within the system <NUM> that use the information provided by the sensors <NUM> to perform a particular operation. The user systems <NUM> may be systems on a vehicle, where the vehicle may be an aircraft, a spacecraft, an automobile, a seacraft, or other movable systems. While the present application refers to the user systems <NUM> as being associated with vehicular navigation, the user systems <NUM> may also be systems within a larger system or a stand-alone system that uses navigation information for non-vehicular purposes. Examples of user systems <NUM> may include a multifunction display, an electronic flight bag, anti-collision systems, weather tracking systems, antenna pointing systems, internal environmental control systems, anti-icing systems, personal navigation devices, biometric devices, among other systems.

The user systems <NUM> may use an estimate of state parameters for a vehicle during operation. Frequently, the user systems <NUM> receive measurements and estimates directly or indirectly from one or more of the sensors <NUM>. When a user system <NUM> receives the estimate, the user system <NUM> may perform an operation that may include maintaining vehicle attitude, controlling pointing functions like weather radars or satellite communications, or driving the autopilot to follow an approach path, among other operations.

While the user systems <NUM> may use estimates of state parameters for the vehicles for automated operations, the estimated state parameters, by themselves, may not support the safe operation of the user systems <NUM>. One or more of the sensors <NUM> may experience faults that may lead to Hazardously Misleading Information (HMI) or Loss of Function (LOF). These HMI or LOF failures lead to unsafe operation risks. The user systems <NUM> may perform safety assessments of the estimated states to reduce the unsafe operation risk. Safety assessments may include accuracy, integrity, continuity, and availability among measurements indicative of the safety of the measured parameters.

As illustrated in <FIG>, the user systems <NUM> may perform safety assessments of the sensors <NUM> based on the operational characteristics and limits of the user system <NUM>. To perform the safety assessments, the user systems <NUM> may use details of the navigation architecture that include specific properties of the sensors <NUM>. The properties of the sensors <NUM> may include the quality of the sensors <NUM>, the specific fault modes of the sensors <NUM>, the redundancies of the sensors <NUM>, and other properties of the sensors <NUM>. Typically, each user system <NUM> performs a static, off-line analysis to perform the safety assessments. The analysis may involve operational procedures or algorithms based on observable data about the sensors <NUM>. This decentralized, static analysis of the sensors <NUM> by the several user systems <NUM> presents several issues that affect the operation of the typical prior art system <NUM>.

In some implementations, complex relationships exist between the potential HMI or LOF conditions for a sensor <NUM> and performable operations by a user system <NUM>. Because of the complex relationships, the user systems <NUM> may perform complex procedures to assure that HMI or LOF for a sensor does not affect vehicle safety. For example, a Minimum Equipment List (MEL) checklist for dispatch of a user system <NUM> or the sensor monitoring procedure used in precision landings that are complex and generally performed by a flight crew. The performance of these and other similar tasks by a flight crew may significantly increase the workload of a flight crew.

As each user system <NUM>, whether manual or automatic, performs a separate safety assessment for the different sensors <NUM>, there is a complex many-to-many dependency between the user systems <NUM> and the sensors <NUM>. The complex many-to-many dependency makes integration of the user systems <NUM> and sensors <NUM> difficult at a vehicle level. Given the many-to-many dependency between the sensors <NUM> and the user systems <NUM> and the resulting difficulties with vehicle integration, the updating of vehicles (in particular aircraft) is difficult after the initial certification of the vehicle. If a new user system <NUM> or sensor <NUM> becomes available within the system <NUM>, the other sensors <NUM> and user systems <NUM> may experience challenges in using the features of the new user system <NUM> or sensor <NUM>. The challenges may include accessing the new information and updating the off-line safety analysis performed with the original user systems <NUM> and sensors <NUM>.

<FIG> is a block diagram illustrating embodiments of a system <NUM> where user systems <NUM> acquire sensor measurements through a fusion function <NUM> and safety assessment information for sensors <NUM> through an abstraction layer <NUM>. The sensors <NUM> function substantially similar to the function of the sensors <NUM> in <FIG>. Additionally, the sensors <NUM> may include multiple sensors that provide measurements redundantly. The user systems <NUM> may perform operations similar to the operations performed by the user systems <NUM> in <FIG>. However, the user systems <NUM> may receive the estimated state through the abstraction layer <NUM> instead of receiving the sensor measurements directly from the multiple sensors <NUM> and performing their own calculations. As used herein, the abstraction layer <NUM> refers to a layer between the sensors <NUM> and the user system <NUM> that provides safety assessment information for consolidated or fused measurements for use by the user systems <NUM>, where the consolidated or fused measurements have been fused by a fusion function <NUM> that receives information from multiple sensors <NUM>. The multiple sensors <NUM> includes at least one set of hardware sensors that provide at least one redundant measurement. Thus, the fusion function <NUM> fuses the information to calculate fused navigation parameters, and the abstraction layer <NUM> calculates safety assessment information for the fused navigation parameters and provides the fused navigation parameters and safety assessment information as an estimated state to the user systems <NUM>. The user systems <NUM> may use the safety assessment information and the fused navigation parameters (which was derived from the sensor measurements and properties) without direct knowledge of the sensors <NUM>, sensor-specific measurements, or sensor properties.

Also, the user systems <NUM> receive safety assessment information through the abstraction layer <NUM> as part of the estimated state instead of each user system <NUM> calculating the safety assessment information. By implementing an abstraction layer <NUM> between the sensors <NUM> and the user systems <NUM>, the user systems <NUM> may operate using the provided estimated state (navigation parameters and safety assessment information) without information related to the properties of the sensors <NUM>.

The fusion function <NUM> receives measurements <NUM> from the sensors <NUM> and provides fused navigation parameters to the abstraction layer <NUM>. The abstraction layer <NUM> additionally calculates safety assessment information and then provides an estimated state <NUM> to the user systems <NUM>. Thus, the estimated state <NUM> includes an estimation of navigation parameters (calculated by the fusion function <NUM>) for the system <NUM> and safety assessment information (i.e., accuracy, integrity, continuity, availability, among other safety assessments) for the state of the system <NUM>. The abstraction layer <NUM> may communicate the estimated state <NUM> directly to the different user systems <NUM>. The safety assessment information calculated by the abstraction layer <NUM> primarily addresses hardware faults in the multiple sensors <NUM>.

As mentioned above, the safety assessment information may describe the accuracy of an estimated state. For example, an accuracy safety assessment measures a difference between an estimated parameter in the estimated state and the actual parameter for the vehicle when there are no failures present. The user systems <NUM> may avoid performing certain operations if the accuracy for a particular state limit exceeds a particular accuracy limit. Additionally, the safety assessment information may describe the integrity of an estimated state. For example, an integrity safety assessment measures the confidence in the correctness of an estimated parameter in the estimated state. When the user system <NUM> receives the integrity safety assessment, the user system <NUM> may emit alarms upon determining that the estimated state parameter is unusable for navigation. Frequently, the integrity safety assessment defines protection levels to limit the effects of potential errors in the estimated state parameters during operation. The protection levels may represent an error bound for an estimated state parameter during operation with a specified probability of exceeding the bound.

Further, the safety assessment information may include a continuity safety assessment. The continuity safety assessment measures the ability of the system <NUM> to provide an estimated state during the operation of the system <NUM>. A user system <NUM> receives the continuity safety assessment in terms of continuity risk, where the continuity risk is the probability that an estimated state becomes unavailable because of loss of service caused by unprogrammed interruptions. Moreover, the safety assessment information may include an availability safety assessment. The availability safety assessment measures the probability that the system <NUM> can produce an estimated state parameter satisfying limits related to accuracy, integrity, and continuity. Additionally, the system <NUM> can exclude measurements from faulted or failed sensors to ensure continuity.

When the abstraction layer <NUM> directly communicates the estimated state <NUM> to the user systems <NUM>, the user systems <NUM> determines whether operations typically performed by the respective user system <NUM> are possible. According to the invention, a user system <NUM> determines that an associated operation is possible by comparing the estimated state <NUM> against operational navigation error limits (e.g., alert limits) for the associated operation. The user system <NUM> may compare the estimated state <NUM> against the operational navigation error limits without determining whether sensors <NUM> are unavailable because they have failed or are faulty.

As stated above, the system <NUM> includes a fusion function <NUM>. The fusion function <NUM> may be a function that receives the measurements <NUM> from the multiple sensors <NUM> and fuses the measurements to calculate navigation parameters as part of the estimated state <NUM>. Hence, the fusion function <NUM> may also be referred to as a consolidation function. The fusion function <NUM> may use brute force techniques to fuse the measurements, statistical filters (e.g., Kalman filtering), or other sensor fusion techniques. When the fusion function <NUM> uses brute force techniques, the fusion function <NUM> may apply different weights to the measurements <NUM> from the multiple sensors <NUM> and identify the weight combinations that yield more accurate measurements. Also, the fusion function <NUM> may apply weights to the measurements <NUM> based on information regarding the integrity or continuity of the measurements provided by the multiple sensors <NUM>. The fusion function <NUM> then provides the fused measurements or fused navigation parameters to the abstraction layer <NUM>.

The system <NUM> may form the abstraction layer <NUM> by determining estimated state parameters that include the accuracy, integrity, continuity, and availability associated with the navigation parameters calculated by the fusion function <NUM>. For example, the abstraction layer <NUM> may use Kalman filtering or other statistical filters to determine the estimated state and accuracy information.

Further, the system <NUM> may form the abstraction layer <NUM> by calculating integrity information. The abstraction layer <NUM> may form the integrity information by communicating the faulted error limits at higher risk levels consistent with higher levels of safety criticality. Typically, integrity risk levels are probabilities of HMI. For example, the different risk levels of safety criticality for the probabilities of HMI may be <<NUM>-<NUM> (minor), <<NUM>-<NUM> (major), <<NUM>-<NUM> (hazardous), and <<NUM>-<NUM> (catastrophic). The abstraction layer <NUM> may communicate a bound of HMI for a risk level by broadcasting a protection level for a particular measurement. The abstraction layer <NUM> may communicate the integrity at multiple risk levels by sending different protection levels for the associated safety-criticality probabilities. When a user system <NUM> receives the different protection levels for a state estimate parameter, the user system <NUM> may select an appropriate protection level for the safety criticality of a particular operation. Additionally, the abstraction layer <NUM> and the fusion function <NUM> may perform exclusions of certain sensor measurements based on the integrity information. For example, the protection levels provided by the abstraction layer <NUM> to the user systems <NUM> may be based on different combinations of measurements from the sensors <NUM>. Further, the user systems <NUM> may perform different actions associated with the different risk levels communicated through the abstraction layer <NUM>. For example, the user system <NUM> may set a bit to indicate that the protection level exceeds a particular threshold for a risk level and what actions can be performed based on the protection levels for a particular risk level.

In some embodiments, the protection bounds calculated by the abstraction layer <NUM> may consider multiple failure types. The different failure types include HMI due to a hardware fault and a failure in a redundant sensor. The different failure types may include a common cause failure such as a GNSS satellite failure, or other already existing standardized failure modes. The bound must also consider fault-free scenarios where the sensor noise alone can lead to HMI. The abstraction layer <NUM> may determine the protection levels using a Kalman filter/solution separation (KF/SS) method, piecewise convolution methods like point mass filters, and other methods. For example, the abstraction layer <NUM> may determine protection levels for a position estimate or other state estimates. Further, the abstraction layer <NUM> may also determine the protection bounds using a fault tree analysis or similar analysis. When using fault tree analysis, a real-time system may perform the analysis. For example, the abstraction layer <NUM> may trade off individual integrity margins to ensure that the estimated state meets a desired integrity.

The system <NUM> may also establish a time to alarm (TTA) as an output used by the user systems <NUM>. Additionally, the system <NUM> may establish multiple TTAs for the different risk levels. In some embodiments, for each parameter in the estimated state, the abstraction layer <NUM> may define any arbitrary combination of the integrity settings (PHMI, TTA, continuity, etc.). The provision of different combinations of the integrity settings is described in greater detail below in connection with <FIG>.

The abstraction layer <NUM> may determine continuity risk using failure rate analysis and fault tree mechanisms while computing an exclusion level. The exclusion level provides a bound on a protected parameter that cannot be exceeded for longer than the time to exclusion (TTE) before measurements produced by the faulted sensor are excluded.

In exemplary embodiments, the abstraction layer <NUM> may communicate continuity risk by synthesizing a composite continuity risk that a user system <NUM> may evaluate against a specific exposure time. The system <NUM> may also provide multiple continuity risk values at different safety probabilities. The system <NUM> may determine the availability using classic assessment methods like an instrument landing system (ILS) signal validation or GNSS availability analysis. The system <NUM> may perform the availability function automatically instead of manually.

In some embodiments, the system <NUM> may use the abstraction layer <NUM> to safely execute a particular operation. For example, the system <NUM> may use information provided by the abstraction layer <NUM> to perform required navigational procedures (RNP) such as an RNP-<NUM> approach. When performing an RNP-<NUM> approach, the system <NUM> may provide a horizontal protection level less than ~<NUM> that corresponds to an integrity level of <NUM>-<NUM> for any operation. The continuity may meet <NUM>-<NUM> for the approach period, which may be ~<NUM> minutes. The user system <NUM> (such as a flight management system (FMS)) may directly look up the alert limit for the <<NUM>-<NUM> (Hazardous) hazard level and compare the looked-up alert limit to the ~<NUM> protection level. The system <NUM> may determine the continuity for this operation by using the continuity failure rate from the abstraction layer <NUM> for the horizontal position and evaluate the horizontal position exclusion capability against the operation time (~<NUM>). If the applicable exclusion level grows during the approach (for example, because of loss of GNSS signals), the operation may be appropriately terminated.

In a further example, the system <NUM> may use the abstraction layer <NUM> when stabilizing an aircraft based on attitude. A flight control unit may receive state estimates for attitudes and an associated <<NUM>-<NUM> (Catastrophic) protection level. If the protection level exceeds the alert limit associated with safe aircraft operation, the system <NUM> may perform emergency procedures. The system <NUM> may also determine continuity for the expected length of a flight by evaluating the failure rate to see if the probability of loss exceeds a value commensurate with its hazard classification, such as <<NUM>-<NUM> tied to the associated attitude bound (Catastrophic). Using an abstraction layer <NUM> may allow flight crews to perform tasks without manually verifying a Minimum Equipment List (MEL).

In certain embodiments, the abstraction layer <NUM> may communicate the estimated state <NUM> to the user systems <NUM> through several communication mechanisms. For example, the abstraction layer <NUM> may communicate the estimated state <NUM> through a full data broadcast, subscription broadcast, or query and response protocols. The protocols may allow for bandwidth optimization on a vehicle associated with the system <NUM>. Also, communication backbones (like ARINC <NUM>) may communicate the estimated state <NUM> at a high data rate. The abstraction layer <NUM> may also communicate the estimated state <NUM> through a hardwired or wireless connection. Further, in some implementations not shown in the figures, the user systems <NUM> may transmit information back to the abstraction layer <NUM>.

In certain embodiments, the system <NUM> may include one or more processors and memory units, where one or more memory units store instructions that direct processors to perform the fusion function <NUM> and implement the abstraction layer <NUM>. Additionally, the user systems <NUM> may also include associated processors and memory units. A processor may be implemented using software, firmware, hardware, or other appropriate combinations thereof. The processor and/or other computational devices may be supplemented by, or incorporated in, specially designed application-specific integrated circuits (ASICs) or field programmable gate arrays (FPGAs). The processor may be a general or special purpose computer or processor, or other programmable logic devices. The processor and other computation devices may also include or function with software programs, firmware, or other computer-readable instructions for carrying out various process tasks, calculations, and control functions used in the present methods and systems.

Further, computer-executable instructions (such as program modules or components) may implement the methods described in this description. At least one processor may execute the computer-executable instructions. Software, firmware, or other execution-capable devices may execute the computer-readable instructions for carrying out various process tasks, calculations, and generation of data used in the operations of the described methods. The computer-readable instructions may be stored as part of one or more appropriate computer-program products, where a computer-program product may be a set of computer-readable instructions or data structures stored on a computer-readable medium. The computer-readable medium may be a media that stores data that the processor or other computing device can access. In certain implementations, the computer-readable medium may form part of a memory unit.

Computer-readable mediums may include non-volatile memory devices. Non-volatile memory devices may include semiconductor memory devices such as random access memory (RAM), read-only memory (ROM), electrically erasable programmable ROM (EEPROM), or flash memory devices. The non-volatile memory devices may also include magnetic disks (such as internal hard disks or removable disks), optical storage devices (such as compact discs (CDs), digital versatile discs (DVDs), Blu-ray discs), or other media that can store computer-executable instructions or data structures.

In exemplary embodiments, the implementation of an abstraction layer <NUM> and fusion function <NUM> allows for much of the specific sensor failure detection, isolation, and re-configuration work to be performed and communicated through the abstraction layer <NUM> instead of being performed by the user systems <NUM>. Further, the data communicated through the abstraction layer <NUM> may be easier for users to understand directly. For example, the total position bound received through the abstraction layer <NUM> may be viewable on a multifunction display plan view. A user may view the total position bound against operational information like the programmed flight plans or local terrain features. Viewing the total position bound against operation information may be a simpler cognitive task than trying to glean that information from the assessment of the individual sensor performances, some of which may not directly measure position.

In further embodiments, for vehicle integrators, reducing the many-to-many dependency between the sensors <NUM> and the user systems <NUM> may divide the integration problem into two parts. The first part being sensors <NUM> to the abstraction layer <NUM>, and the second part being the abstraction layer <NUM> to the user systems <NUM>. The division of integration may reduce the number of required interfaces and the complexity of the system <NUM> by an order of magnitude. The abstraction layer <NUM> may be easy to simulate and validate from both the side of the sensors <NUM> and the side of the user system <NUM>.

In additional embodiments, the user systems <NUM> may benefit as the abstraction layer <NUM> may provide improved performance concerning the estimated state <NUM>. The improved performance may facilitate upgrading the user systems <NUM> to incorporate additional operational capabilities without changing the sensors <NUM> or updating the sensor analysis. For example, the abstraction layer <NUM> may provide the estimated state <NUM> to the user systems <NUM>, where the estimated state <NUM> is determined by the abstraction layer <NUM> independent of characteristics of the user systems <NUM>. Accordingly, the user systems <NUM> can be upgraded, changed, reconfigured, degrade, or experience any other change in operation without affecting the consolidated state estimate provided by the abstraction layer <NUM>. Additionally, the only connection to be made between a user system <NUM> and the sensors <NUM> is the connection between the user system <NUM> and the abstraction layer <NUM>. Thus, changing or adding a user system <NUM> affects a single connection, which is an improvement over the multiple affected connections that would result from changing the user systems <NUM> in <FIG>.

In some embodiments, breaking the many-to-many dependency, illustrated in <FIG>, using the abstraction layer <NUM> may also facilitate adding sensors <NUM>. The addition of sensors <NUM> may be visible through the abstraction layer <NUM> as the estimated state <NUM> may improve because of the additional sensors <NUM>. For example, when adding a sensor <NUM>, the fusion function <NUM> fuses the measurements from the added sensor <NUM> with the already connected sensors <NUM>. Based on the characteristics of the added sensor <NUM> and the measurements from the added sensor <NUM>, the abstraction layer <NUM> calculates a new estimated state <NUM>. The abstraction layer <NUM> will then provide the new estimated state <NUM> to the user systems <NUM>. As stated, the user systems <NUM> are indirectly aware that configuration changes have occurred to the sensors <NUM> because of changes in the estimated state <NUM> provided by the abstraction layer <NUM>. However, the user systems <NUM> are unaware of any specific changes to the configuration of the sensors <NUM>. Thus, the abstraction layer <NUM> and the fusion function <NUM> simplify updating and certifying the system <NUM> along with the operation of any associated vehicles because the sensors <NUM> and user systems <NUM> can be updated by connecting the changed sensors <NUM> and user systems <NUM> to the fusion function <NUM> and the abstraction layer <NUM>, where the fusion function <NUM> and the abstraction layer <NUM> make adjustments for changes to the system <NUM>.

<FIG> is a table illustrating exemplary information provided to the user systems <NUM> through the abstraction layer <NUM>. As shown, the abstraction layer <NUM> may present an estimated state <NUM> that shows estimated state parameters for a system. The estimated state <NUM> refers to the estimated state of a vehicle or other object based on the fused measurements from the available sensors <NUM>. As shown, the estimated state <NUM> may show estimated parameters and information describing the parameters for rates/accelerations <NUM>, attitudes <NUM>, headings <NUM>, velocities <NUM>, positions <NUM>, altitudes <NUM>, air data <NUM>, and additional information <NUM>. The list of information presented in the estimated state <NUM> is not all-inclusive, and other information related to the state of the aircraft may be shown. The estimated state <NUM> may also be referred to as a consolidated state or fused state as the presented estimated state <NUM> represents the information after the abstraction layer <NUM> and fusion function <NUM> consolidate (fuse) the measurements from multiple sensors.

In some embodiments, the estimated state <NUM> may provide information related to the various estimated state parameters. For example, the estimated state <NUM> may provide a value <NUM>, where the value <NUM> represents an estimate of a particular parameter <NUM>. Also, the estimated state <NUM> may provide an accuracy assessment <NUM>, where the accuracy assessment <NUM> is a value showing the accuracy associated with a parameter <NUM>. For example, the accuracy assessment <NUM> may show a <NUM>% accuracy value for a parameter <NUM>.

In additional embodiments, the estimated state <NUM> may provide integrity information <NUM> for the provided parameters <NUM>. The integrity information <NUM> may include a minor protection level and/or exclusion threshold <NUM>, where the minor protection level and/or exclusion threshold <NUM> corresponds to a minor hazard with a probability <<NUM>-<NUM>. The integrity information <NUM> may also include a major protection level and/or exclusion threshold <NUM>, where the major protection level and/or exclusion threshold <NUM> corresponds to a major hazard with a probability <<NUM>-<NUM>. The integrity information <NUM> may also include a hazardous protection level and/or exclusion threshold <NUM>, where the hazardous protection level and/or exclusion threshold <NUM> corresponds to a hazardous hazard with a probability <<NUM>-<NUM>. The integrity information <NUM> may also include a catastrophic protection level and/or exclusion threshold <NUM>, where the catastrophic protection level and/or exclusion threshold <NUM> corresponds to a catastrophic hazard with a probability <<NUM>-<NUM>. The integrity information <NUM> may also include a time-to-alert <NUM>, where the time-to-alert is the interval of time between when a fault causes an integrity protection level to be exceeded and when the fault is annunciated in the outputs or mitigated, such as by sensor exclusion.

In further embodiments, the estimated state <NUM> may include continuity information <NUM>. The continuity information <NUM> may include a continuity risk <NUM>, where the continuity risk <NUM> is an estimate of the risk associated with a loss of function for the parameter based on a current operational state of sensors <NUM> and fusion function. The user systems <NUM> may use the continuity risk to determine probabilities for loss of function based on applicable exposure times for the user systems <NUM>.

<FIG> is a table showing the estimated state <NUM>, where the table shows the calculation of estimated parameters for different combinations of integrity settings. For example, the estimated state <NUM> may estimate different protection levels for different TTAs. As shown, the estimated state <NUM> may have three different TTAs for the estimated parameters for rates/accelerations <NUM>-A-<NUM>-B. For the first rate/acceleration parameter <NUM>-A, the abstraction layer <NUM> and fusion function <NUM> may calculate a protection level and/or exclusion level <NUM> having a first value that is associated with a first TTA (TTE) value. Additionally, for the second rate/acceleration parameter <NUM>-B, the abstraction layer <NUM> and fusion function <NUM> may calculate a protection level and/or exclusion level <NUM> having a second value that is associated with a second TTA (TTE) value. Moreover, for the third rate/acceleration parameter <NUM>-C, the abstraction layer <NUM> and fusion function <NUM> may calculate a protection level and/or exclusion threshold <NUM> having a third value that is associated with a third TTA (TTE) value. As shown, the abstraction layer <NUM> and fusion function <NUM> calculate the other estimated parameters and associated values in much the same way as described above in <FIG>. By computing different combinations of integrity settings, the abstraction layer <NUM> and the fusion function <NUM> allow user systems <NUM> to select a protection level (or other measurement) associated with a desired TTA (TTE) or other value.

<FIG> is a flowchart diagram illustrating a method <NUM> for the operation of the fusion function <NUM> and the abstraction layer <NUM> as described above. Within the fusion function <NUM>, the method <NUM> proceeds at <NUM>, where measurements are received from multiple sensors. The method <NUM> proceeds at <NUM>, where the measurements are fused to create fused measurements.

In additional embodiments, within the abstraction layer <NUM>, the method <NUM> proceeds at <NUM>, where the fused measurements are received from the fusion function. Further, the method <NUM> proceeds at <NUM>, where sensor properties are identified. Also, the method <NUM> proceeds at <NUM>, where an estimated state is calculated based on the fused measurements and the sensor properties. Moreover, the method <NUM> proceeds at <NUM>, where the estimated state is provided as an output. As described above, the estimated state includes safety assessment information and the fused measurements. The user systems <NUM> may then use the information in the estimated state during their operation.

<FIG> is a flowchart diagram of a method <NUM> for providing an estimated state to user systems. The method <NUM> proceeds at <NUM>, where redundant sensor measurements and sensor properties are received from a plurality of sensors. For example, the redundancy of the redundant sensor measurements is achieved based on an independence between measurements from different physical sensor units. The method <NUM> also proceeds at <NUM>, where fused navigation parameters are calculated based on a fusion of the redundant sensor measurements and the sensor properties. Further, the method <NUM> proceeds at <NUM>, where the estimated state is provided to a plurality of user systems through an abstraction layer, where the estimated state includes the fused navigation parameters and safety assessment information for the fused navigation parameters.

Claim 1:
A method comprising:
receiving, by a fusion function, redundant sensor measurements from a plurality of sensors (<NUM>) that comprise at least an inertial measurement unit, wherein redundancy of the redundant sensor measurements is achieved based on an independence between measurements from different physical sensor units;
calculating, by the fusion function, fused navigation parameters based on a fusion of the redundant sensor measurements; and
providing, by the fusion function, fused navigation parameters to an abstraction layer;
calculating, by the abstraction layer, an estimated state, wherein the estimated state comprises the fused navigation parameters and safety assessment information for the fused navigation parameters, wherein the safety assessment information describes the accuracy of the fused navigation parameters of the estimated state;
providing, by the abstraction layer, the estimated state directly to a plurality of user systems;
determining, by a user system in the plurality of user systems, whether operations typically performed by the user system are possible based on comparing the estimated state against operational navigation error limits for the operations.