Classifications

• • G—PHYSICS
  • G08—SIGNALLING
  • G08G—TRAFFIC CONTROL SYSTEMS
  • G08G5/00—Traffic control systems for aircraft, e.g. air-traffic control [ATC]
  • G08G5/0004—Transmission of traffic-related information to or from an aircraft
  • G08G5/0013—Transmission of traffic-related information to or from an aircraft with a ground station
• • G—PHYSICS
  • G01—MEASURING; TESTING
  • G01S—RADIO DIRECTION-FINDING; RADIO NAVIGATION; DETERMINING DISTANCE OR VELOCITY BY USE OF RADIO WAVES; LOCATING OR PRESENCE-DETECTING BY USE OF THE REFLECTION OR RERADIATION OF RADIO WAVES; ANALOGOUS ARRANGEMENTS USING OTHER WAVES
  • G01S13/00—Systems using the reflection or reradiation of radio waves, e.g. radar systems; Analogous systems using reflection or reradiation of waves whose nature or wavelength is irrelevant or unspecified
  • G01S13/66—Radar-tracking systems; Analogous systems
• • G—PHYSICS
  • G01—MEASURING; TESTING
  • G01S—RADIO DIRECTION-FINDING; RADIO NAVIGATION; DETERMINING DISTANCE OR VELOCITY BY USE OF RADIO WAVES; LOCATING OR PRESENCE-DETECTING BY USE OF THE REFLECTION OR RERADIATION OF RADIO WAVES; ANALOGOUS ARRANGEMENTS USING OTHER WAVES
  • G01S13/00—Systems using the reflection or reradiation of radio waves, e.g. radar systems; Analogous systems using reflection or reradiation of waves whose nature or wavelength is irrelevant or unspecified
  • G01S13/87—Combinations of radar systems, e.g. primary radar and secondary radar
• • G—PHYSICS
  • G01—MEASURING; TESTING
  • G01S—RADIO DIRECTION-FINDING; RADIO NAVIGATION; DETERMINING DISTANCE OR VELOCITY BY USE OF RADIO WAVES; LOCATING OR PRESENCE-DETECTING BY USE OF THE REFLECTION OR RERADIATION OF RADIO WAVES; ANALOGOUS ARRANGEMENTS USING OTHER WAVES
  • G01S13/00—Systems using the reflection or reradiation of radio waves, e.g. radar systems; Analogous systems using reflection or reradiation of waves whose nature or wavelength is irrelevant or unspecified
  • G01S13/88—Radar or analogous systems specially adapted for specific applications
  • G01S13/91—Radar or analogous systems specially adapted for specific applications for traffic control
• • G—PHYSICS
  • G01—MEASURING; TESTING
  • G01S—RADIO DIRECTION-FINDING; RADIO NAVIGATION; DETERMINING DISTANCE OR VELOCITY BY USE OF RADIO WAVES; LOCATING OR PRESENCE-DETECTING BY USE OF THE REFLECTION OR RERADIATION OF RADIO WAVES; ANALOGOUS ARRANGEMENTS USING OTHER WAVES
  • G01S7/00—Details of systems according to groups G01S13/00, G01S15/00, G01S17/00
  • G01S7/003—Transmission of data between radar, sonar or lidar systems and remote stations
• • G—PHYSICS
  • G08—SIGNALLING
  • G08G—TRAFFIC CONTROL SYSTEMS
  • G08G5/00—Traffic control systems for aircraft, e.g. air-traffic control [ATC]
  • G08G5/0017—Arrangements for implementing traffic-related aircraft activities, e.g. arrangements for generating, displaying, acquiring or managing traffic information
  • G08G5/0026—Arrangements for implementing traffic-related aircraft activities, e.g. arrangements for generating, displaying, acquiring or managing traffic information located on the ground
• • G—PHYSICS
  • G08—SIGNALLING
  • G08G—TRAFFIC CONTROL SYSTEMS
  • G08G5/00—Traffic control systems for aircraft, e.g. air-traffic control [ATC]
  • G08G5/0073—Surveillance aids
  • G08G5/0082—Surveillance aids for monitoring traffic from a ground station
• • G—PHYSICS
  • G01—MEASURING; TESTING
  • G01S—RADIO DIRECTION-FINDING; RADIO NAVIGATION; DETERMINING DISTANCE OR VELOCITY BY USE OF RADIO WAVES; LOCATING OR PRESENCE-DETECTING BY USE OF THE REFLECTION OR RERADIATION OF RADIO WAVES; ANALOGOUS ARRANGEMENTS USING OTHER WAVES
  • G01S13/00—Systems using the reflection or reradiation of radio waves, e.g. radar systems; Analogous systems using reflection or reradiation of waves whose nature or wavelength is irrelevant or unspecified
  • G01S13/86—Combinations of radar systems with non-radar systems, e.g. sonar, direction finder
• • G—PHYSICS
  • G01—MEASURING; TESTING
  • G01S—RADIO DIRECTION-FINDING; RADIO NAVIGATION; DETERMINING DISTANCE OR VELOCITY BY USE OF RADIO WAVES; LOCATING OR PRESENCE-DETECTING BY USE OF THE REFLECTION OR RERADIATION OF RADIO WAVES; ANALOGOUS ARRANGEMENTS USING OTHER WAVES
  • G01S7/00—Details of systems according to groups G01S13/00, G01S15/00, G01S17/00
  • G01S7/02—Details of systems according to groups G01S13/00, G01S15/00, G01S17/00 of systems according to group G01S13/00
  • G01S7/28—Details of pulse systems
  • G01S7/285—Receivers
  • G01S7/295—Means for transforming co-ordinates or for evaluating data, e.g. using computers

Definitions

• the present invention relates to a system for sharing vehicle telemetry data between a plurality of sensors of different types and a plurality of users of different types. More particularly, the present invention relates to a system whereby vehicle telemetry information is shared on an "as needed" basis in order to reduce the communications bandwidth required among the various sensors and users. Preferably, communications among the various sensors and users is carried out in a common data format to enhance system integrity and, again, reduce bandwidth requirements.
• each sensor broadcasts its data to the entire system at a selectable interval, and all users receive all data.
• certain users may request special updates from selected sensors.
• a communications bandwidth problem arises which may lead to system breakdown or, at the least, late reception of vital data.
• an aircraft may receive delayed other- vehicle course and speed information because of an incoming wind shear update.
• the above-noted problems are exacerbated because of the different data formats used by the various sensors and users.
• the co nmunications network may simply be expanded to provide increased bandwidth, but this is expensive, time-consuming, and has to be carried out for each incremental increase in number of sensors and/or users.
• one or more computer-readable storage mediums containing one or more computer programs for causing one or more computers to distribute vehicle track data over a communications network to a plurality of users each of which comprises a sensor and an operational unit causes the one or more computers to perform the steps of: (i) sensing a vehicle track with a first sensor of a first user; (ii) generating, at the first user, a first current observation related estimate based on the sensed vehicle track and reporting needs; (iii) transmitting the first current observation related estimate to the communications network when it is determined that the first current observation related estimate will improve a predetermined vehicle track profile; (iv) receiving, at the first user, a second current observation related estimate generated by a second user and transmitted over the communications network; (v) fusing , at the first user, the first current observation related estimate and the second current observation related estimate to provide a fusion algorithm combined track; and (vi) providing the fusion algorithm combined track to a first operational unit.
• Figure 4 is a functional depiction of the comparing operation for deciding whether or not to report a CORE to the communication network.
• FIG. 5 is a notional depiction of the DCN DM structure and functions to be described below.
• the telemetry data of an aircraft 20 is detected by a radar 1, by a radar 2, by an infrared sensor 4, and by a radar 3 which is mounted in a second aircraft 6.
• each sensor has a corresponding user to which it provides the telemetry data sensed by the associated sensor.
• radar 1 may be an airport radar which radios the sensed telemetry data to an associated user 11 which may comprise one or more processors in the Control Tower which provide information to the Air Traffic Control staff.
• the radar 2 may comprise a newer-style radar directly coupled to a user 21 processor which monitors telemetry data for an airline.
• Infrared sensor 4 may provide sensed telemetry data over a landline to a processor of user 41 which supplies information to a weather network.
• the embodiment of Figure 1 presents an architecture for an extensible, evolvable, multi-level sensor data fusion system that creates a distributed data base from multiple sensors.
• the data is fused because it combines vehicle track state data (e.g., position and rate measurements) from multiple radar or other multi-dimensional sensors. These sensors may be located at multiple sites.
• vehicle track state data e.g., position and rate measurements
• These sensors may be located at multiple sites.
• the data base is distributed because each sensor and/or user stores both the vehicle information it acquires and the vehicle information it obtains from the other sensors/users over the communications network.
• the sensor measurements are processed locally, and resulting information is exchanged over a communications network comprising one or more data distribution networks.
• the networks can be limited in bandwidth, but typically should have transmission delays that are on the order of the measurement period of the sensors, or smaller, to derive the best performance from the process.
• Each Data User requests, over the communications network, the level of track accuracy it needs (e.g., vehicle speed within plus or minus 5 feet per second) according to track identity (e.g., which aircraft), type (e.g., aircraft size), category (e.g., commercial), status (e.g., landing), geographic location (e.g., in the landing pattern), etc. These requests are mapped to the Data User's "Reporting Needs" for each vehicle track.
• the Data Sources then provide, over the communications network, the level of data appropriate to the requesting Data User to support the requested Reporting Needs. This requesting and supplying of information on an "as needed" basis controls the growth in distribution bandwidth requirements to a level that can be supported in large, widely distributed multi-level user networks.
• the functional components of the system are structured to allow single-point additions of or changes to Data Sources and Data Users.
• the addition of new sources and users does not affect the computational complexity of the existing network components for a given number of supported tracks.
• This de-coupled component structure is designed in such a way that existing components need no modification for new components to use and contribute to network data.
• Components of widely distributed multi-level Data User networks may not have bandwidth available to share a set of identical complete vehicle track data throughout the networks at the accuracy required by the most demanding Data Users. However, they can share highly accurate track data requested by specific users while supporting other levels of track accuracy according to Data User requests.
• Data Users request data by track identity, type, category, geographic location, at the situation awareness level, the planning level, or the maneuvering level.
• Data are accumulated, condensed, registered, and distributed as needed in a common geodetic coordinate frame with corresponding ellipsoidal covariance information. These messages are called "Current Observation Re.ated Estimates" (CORE).
• the CORE fusion function (to be described below) it each Data User assembles the Common Frame Track Picture from this low bandwidth data wit lout the need for source location or sensor identity information.
• FIG. 2 depicts the exchange of CORE and FACTs.
• CORE are created from sensor measurement data at each Data Source 11 and 21, and distributed in a common recognizable form throughout the low-latency network for use by CORE fusion functions 12 and 22. Network data distribution is managed by Distribution Processing 13 and 23.
• CORE fusion functions 12 and 22 create Fusion Algorithm Combined Tracks (FACTs) for use by local platform functions that need vehicle track states. These functions are part of the Data Users and Data Sources.
• FACTs Fusion Algorithm Combined Tracks
• Figure 3 is an information flow diagram showing the interaction between the key functions within a Data Source and with a CORE Fusion and Distribution Processing function.
• the Data Source includes all functions necessary to support a sensor's interaction with CORE Fusion and with a distribution network.
• the Data Source's primary function is to create CORE from its corresponding sensor's data based on identified Reporting Needs.
• CORE are distributed through a network to CORE Fusion utilities at each network node where they update the corresponding FACTs.
• FACT states are sent to the Data Sources for use in the creation of CORE and the association of sensor data.
• GRIP Geodetic Registration Information Processing
• the hypotheses selected by ACE is used by the State Testing and Adaptive Reporting (STAR) function to determine if a CORE should be created from the selected Local Estimate.
• STAR State Testing and Adaptive Reporting
• the corresponding FACT covariance is predicted to the current time and used to determine the immediate need for sensor data.
• the value of distributing a CORE produced from the Local Estimate is calculated.
• the immediate need and the added value are compared (to be described in greater detail below) to determine if a CORE is to be produced. The manner of comparison ensures that a CORE is produced only if it is needed and if the Local Estimate will currently offer the greatest improvement of all sources in the network.
• CORE are most often distributed as 6-state estimates. However, 9-state and 3-state CORE are distributed for certain conditions and vehicle dynamics.
• the Data Fusion process uses these types of CORE to improve the FACT state. That improved state is available to local node Data Users and Data Sources. Data Sources then use the updated FACT in the STAR reporting decision and in CAT correlation and measurement association.
• De-coupling in the structure of the CORE Fusion Process results in large part from the decoupling of the registration and fusion processes. Localization and alignment occur in the Data Source. Data are then distributed in a geodetic frame using full covariance information, thus they are readily interpreted by all users without knowledge of the source location or type. Registration occurs at multiple levels simultaneously to ensure a robust solution. Registration results from all available data are combined to provide the most accurate solution.
• the improved FACT error (quantity on the left) is computed and subtracted from the predicted FACT error (quantity on the right). The difference is compared against a subsequent threshold to determine if a CORE should be sent. It is this latter comparison that ensures that STAR distributes the most valuable data, thereby preempting the prolific distribution of lower value data, thus conserving communication bandwidth.
• this algorithm reduces computational and data distribution complexity by a full computational order. It thereby enables networks to meet otherwise unattainable specifications for network size and track capacity, accuracy, and concurrency. It also provides a greater flexibility in the selection of appropriate data distribution equipment by driving bandwidth requirements down to the realm of commercial radios.
• the magnitude of the predicted FACT rate error ellipsoid's largest dimension at the time of the Local Estimate is calculated by predicting the FACT to the time of the LE, and determining the largest eigenvalue of the rate covariance.
• the magnitude of the FACT rate error ellipsoid's largest dimension if a CORE were distributed is calculated by computing the filtered rate error that results from updating the FACT with the CORE and determining the largest eigenvalue of that rate covariance.
• CORE from all sources are fused in the CORE Fusion functions at each network segment by a robust vehicle-oriented filter that produces the FACTs.
• CORE Fusion also can fuse FACT data and connect networks by correlating FACT data from different networks operating at different Reporting Needs.
• the features of the present invention may be incorporated into existing sensor and user processors as software updates and/or processor enhancements. Also, it is envisaged that additional processors, which have the herein-described functionality incorporated therein, may be added to existing systems at the sensor side and/or at the user side. It is believed that once this system gains widespread acceptance, all hardware created for vehicle telemetry purposes will have this functionality built-in. Accordingly, the functions described herein may be incorporated as software only, hardware only, or a combination of software and hardware.
• the software may be encoded in any known medium such as hard discs, floppy discs, firmware, hardware, optical media, etc.
• processors described herein may be one or more singular, isolated processors, distributed processors, shared processors, co-located processors, remote processors, or any other processor architecture able to sense and share vehicle telemetry data.
• DCN/DM Distributed Component Network/Dynamic Middleware
• the DCN/DM provides an architectural framework that directly addresses desired system characteristics. Rather than decompose the system based on functional areas such as detect/control/maneuver, the present invention is premised on an object-based decomposition of the system into its distinct elements such as control, sensor, or Digital Information Link (DIL) forwarder/router. These element objects are then coupled with supporting objects and networked together as building blocks for more complex structures. These blocks are bound together through a middleware "glue", which ensures component independence.
• DIL Digital Information Link
• DM Dynamic Middleware
• ODF Visualization
• Messaging A notional DCN/DM structured segment is shown in Figure 5.
• Sensor Server 14 manages correlation, association, and tracking for the local sensor. Processing is optimized for the specific sensor.
• the server 14 provides the Data Conditioner 15 with Associated Measurements (AMRs) as well as new tracks.
• the server 14 may be developed by the sensor element owner because the domain knowledge of the server is highest at the source.
• Each Data Conditioner function 15 provides generic interface for exchange of sensor information with element servers. It also provides needs/accuracy-based data distribution. Finally ech data conditioner accumulates and distributes AMRs as Current Observation-Related Estimates (CORE) to local and remote CORE Synthesis utilities, based on needs expressed by the end user and the resulting improvement in the network track state.
• CORE Current Observation-Related Estimates
• CORE Synthesis function 16 fuses CORE data with the network track state into a Fusion Algorithm Combined Track (FACT) for use by element servers and Data Conditioners.
• FACT Fusion Algorithm Combined Track
• Messaging functions within the communications network 5 and each processor operate to distribute local CORE, receive remote CORE, and receive remote reporting needs.
• Each sensor server will be programmed to carry out the following functions:
• the measurement conversion function transforms a measurement in sensor spherical coordinates to a measurement in the WGS84 coordinate system, a universal common coordinate system.
• MC requires as input the measurement in spherical coordinates (range, bearing, and elevation), the sensor's estimated geodetic location (latitude, longitude, and altitude), the nort l-pointing b.as estimate, and the uncertainties associated with these quantities.
• the MC algorithm below gives the computation of the converted measurement with a correction for the estimated north-pointing bias. This is the measurement specified as the input to Adaptive Curve Estimation (ACE). Parametric Adaptive Curve Estimation (PACE) requires the converted measuremem without the bias correction.
• ACE Adaptive Curve Estimation
• the uncorrected measurement converted to the sensor's local coordinate system is an intermediate product of computing the PACE input. This local converted measurement is currently a specified input for the GRIP function.
• T m Sensor measurement time in seconds.
• R Range measurement on track in meters.
• H Estimated sensor WGS84 Geodetic altitude in meters at time T m .
• ⁇ p Standard deviation of estimated north-pointing bias.
• Transforming from local coordinates to WGS84 coordinates uses the estimated sensor position. Add the uncertainty in the measured local origin to R L .
• R L R L + R S
• the measurement error covariance matrix is given by the following,
• PACE maintains a six-state estimate of the vehicle in WGS-84 coordinates with a finite memory filter. Assuming between m and 2m measurements are maintained in the filter memory, when 2m measurements have been accumulated, the first m measurements are erased from the filter's memory. The measurements in the finite memory filter could also be referred to as a sliding window of measurements. The distribution of each new measurement residual is tested and, depending on the results of the test, the filter is either updated with the measurement or the measurement is stored for later use. The measurement residual is the difference between the measurement and the predicted position of the vehicle at the time of the measurement. If some number, n, of consecutive measurements fail the residual test, a vehicle maneuver is declared.
• the filter is extrapolated from a time prior to the n measurements that declare a maneuver and the n measurements have not been used to update the filter. Updating the filter with the measurements that declare the maneuver could possibly delay the declaration of the maneuver.
• the measurement residuals For a non-maneuvering vehicle, the measurement residuals have a normal distribution with a mean of 0 and a covariance matrix that is the sum of the covariance of the measurement and the covariance of the predicted state. After a vehicle has begun a maneuver, the measurement residuals begin to fall outside of this distribution. Thus, the maneuver hypothesis tests the distribution of n consecutive residuals.
• n and m may vary depending on the characteristics of the sensor such as update rate and measurement accuracy.
• PACE has been simulated with a sensor update rate of one measurement per second and performs well when three consecutive failures are required with between 20 and 40 measurements in the filter memory.
• a false declaration occurs because of random statistical fluctuations in the innovation sequence.
• a straight-line trajectory may induce a false maneuver detection if n consecutive residuals are large; however, since the random system noise is assumed to be zero-mean Gaussian noise, it is far less likely that these large residuals will be on the same side of the straight line trajectory.
• the system model is assuming a straight-line trajectory, then consecutive residuals are very likely to be on the same side of the assumed straight-line trajectory. However, if the trajectory has a change in speed but not a change in direction, the residuals are not as likely to fall on the same side of the trajectory.
• a sign test may accept the null hypothesis when there is in fact a maneuver. In order to detect both a change in direction as well as a change in speed, the current implementation of PACE does not employ a sign test.
• the chi-squared test takes advantage of all the available information.
• the probability of a false detection is the probability that all n residual tests have a false detection; thus, for the hypothesis test to have a confidence level of x percent, the individual residual tests must have a confidence level of y - 1 - e 1 '" 1 ⁇ 1" ⁇ percent.
• the residuals are tested with the chi-squared value, ⁇ (y,3) .
• Section 5.1.2 below includes the equations and an algorithm summary for the statistical test.
• the filter estimates a straight line through the measurements in the maneuver and the measurements used in the residual test fall to one side of the filter's predicted state estimate.
• the measurements will continue to fail the residual test until the filter memory consists of non-maneuvering data.
• the end of the maneuver is declared. Since the oldest measurements in the filter's memory may have occurred during the maneuver and may subsequently trigger a false maneuver detect, the filter memory is cleared after the end of the maneuver is declared.
• the maneuver end detect test needs to be based on a statistically significant number of measurements without degrading the response time to the end of the maneuver.
• the filter is reinitialized and p measurements, n ⁇ p ⁇ m, are accumulated before testing for the end of the maneuver is begun. Similar to the test for detecting the maneuver, n consecutive residuals must pass the residual test before the end of the maneuver is declared. For maneuvers of short duration, this test will overestimate the time at which the maneuver ended due to the number of measurements needed to initialize the filter.
• at least p-1 measurements must be received after a maneuver is declared before the end of the maneuver can be detected. For longer maneuvers, PACE is less likely to declare the end of the maneuver too soon.
• a sliding window filter must have a reasonable number of measurements in its window to perform statistical tests but at the same time fade out measurements of the maneuvering hypothesis so that it can detect the end of the maneuver.
• An advantage of the current implementation of PACE is that the filter does not remember old data. Operating the filter over a sliding window of measurements allows the estimate to be determined by the most recent measurements.
• an apparent disadvantage of the above implementation of PACE is the inability to quickly detect the end of the manevuer.
• the fewer the measurements used to initialize a filter the more false detects there will be following initialization.
• the trade-off is longer maneuvers versus fewer false detects, both maneuver begin detects and maneuver end detects.
• the measurements are processed like they are in the regular Kalman filter with a q-value of 0. However, old measurements are periodically dropped from the filter estimate. If the desired length of the sliding window is r measurements, then the filter is initialized and updated as usual with a q-value of 0. When r measurements have been accumulated, the filter estimate is stored as (t r ,x r ,P r ) , representing the time, state and covariance of the filtered estimate respectively. The filter continues to be updated until 2*r measurements have been accumulated. At this point, the first r measurements are deleted from the filter memory according to the following equations:
• the filter is then updated with x ⁇ and R 2 ( r r) as its initial conditions. After accumulating the first r measurements, the filter estimate is conditioned on the last r to 2r measurements. 5.1.2 PACE Algorithm
• R k measurement error rotated into WGS-84 x, y and z
• a local track estimate in the LEARN file comprises a sequence of state estimates along with the corresponding sequence of converted measurements. Maintaining a sequence of measurements allows the computation of nine-state estimates only when they are needed which results in significant computational savings over continuously maintaining and updating a nine-state estimate. Maintaining the sequence of updated estimates permits the processing of estimates that are not in time order. This could happen in the case of a Link Data Conditioner (LDC) where measurements from two or more sensors are feeding into the single LDC. In practice, a large number of measurements could be used in forming the current LEARN file estimate. To prevent unlimited growth of the sequence of measurements and updates, only the N most recent for some number N are saved.
• LDC Link Data Conditioner
• ACE When a measurement arrives out of time order, it is inserted into the measurement list in the correct slot such that the list is time-ordered. ACE then begins with the state estimate previous to the out-of-order-measurement and updates the state estimate by filtering the sequence of measurements from the out-of-order measurement on to the most recent measurement.
• inputs to ACE include sensor measurements registered and converted into geodetic coordinates and track maneuver information from the PACE function.
• ACE Upon receiving an AMR, ACE checks the number of AMRs accumulated in the measurement sequence. If there have been no AMRs accumulated, ACE saves the AMR as the first measurement on the list. If there is only one saved AMR, ACE uses the old AMR along with the measurement on the list. If there is only one saved AMR, ACE uses the old AMR along with the new one to initialize a six-state estimate on the track. If there is more than one old AMR on the list, ACE uses the new AMR to update the six-state estimate via a Kalman Filter update.
• the Q matrix used is constructed by selecting between a high and a low q value depending on the maneuver indication by PACE: the high q value is used when PACE indicates that the track is maneuvering and the low q value is used otherwise.
• ACE must also operate on the LEARN file estimate in response to updates of the FACT estimate by CORE Synthesis. If STAR decides to send a six-state CORE generated from the LEARN file estimate, then ACE wipes-out the current LEARN file estimate by setting the saved measurement and update lists to all zeros. Subsequent AMRs are used to reinitialize a new LEARN estimate on the track. Similarly, if STAR decides to send a nine-state CORE, then the AMRs that were used to construct the CORE must be deleted from the list. Any remaining AMRs in the measurement file are used to initialize a new LEARN file estimate on the track. Update of the FACT by a nine-state CORE results in similar processing. In this case, ACE wipes-out the track's update file and also deletes AMRs from the measurement file if their times are before maneuver start time sent with the nine-state CORE.
• State Estimate Sequence List a data structure containing up to some number, N, of the most recent updated track estimates (time, X, VX, Y, NY, Z, VZ, and the upper triangular portion of the 6x6 covariance matrix, P. Note: the State Estimate Sequence only has to be maintained if the possibility of AMRs arriving out of time order is allowed. If AMRs are always in time order, the history of state estimates is not needed.
• Updates of the LEARN file estimate either incorporating the new measurement information or adjusting for a nine-state or local six-state update of the FACT estimate.
• ⁇ OUTPUT (nine-state estimate: time, position, velocity, acceleration, and 9x9 covariance matrix, P).
• N t the number of AMRs in the AMR list with time ⁇ PACE_Maneuver_Onset_Time.
• the SFACT estimate is a fusion of the current CORE and FACT estimates that is sent to the Sensor Server for use by the Correlation, Association and Tracking (CAT) function. It is one of the pieces of information stored in the Sensor Measurement Association & Resolution Track (SMART) file in the Sensor Server.
• the SFACT estimate is updated in response to one of two events:
• SFACT covariance calculation is the same is the same set of equations used in computing the Filtered Test Value in STAR. I.e., STAR is also computing the SFACT covariance matrix. Thus computing the covariance matrix in Update_FACT and then passing it into STAR as input can save computation. Since Update SFACT may have to be modified once the CAT function has been specified, we will not change the STAR inputs for now.
• Event_Flag FACT_Update_By_Local_CORE
• State Testing and Adaptive Reporting is responsible for determining the value of the state information in a CORE relative to the improvement in the FACT estimate on the track that would result from updating with the CORE. If STAR determines that the CORE will improve the composite track estimate in the FACT, then the CORE will be distributed across the network.
• a nine-state CORE is generated whenever PACE first detects that a track has begun to maneuver. The nine-state CORE is needed by CORE Synthesis to increase the FACT estimate from six to nine states. Thus, if the FACT estimate is six-states, then STAR distributes a nine- state CORE to the network without any testing. The real problem for STAR is to determine when to distribute a six-state CORE.
• the decision whether or not to send a six-state CORE is based on a test of the accuracy of the FACT estimate with the CORE information versus the accuracy of the FACT estimate predicted without the CORE information.
• STAR begins the evaluation by predicting the FACT estimate to the time of the current CORE. From the predicted covariance matrix, a submatrix corresponding to the rate-only variances and covariances is extracted; the square root of the maximum eigenvalue of this submatrix is the Predicted_Test_Value. If the Predicted_Test_Value is less than some threshold (STARJLower Threshold), then the FACT is more than accurate enough without the CORE information, so the immediate decision is not to send the CORE. If the Predicted_Test_Value exceeds some threshold (STAR_Upper_Threshold), then the FACT does not have acceptable accuracy and thus the immediate decision is to send the CORE without further testing.
• Test values used in the STAR test (for analysis only).
• Step 1 Obtain the error covariance matrix P t _ 1/t _, from the FACT.
• Step 2 Compute the predicted error covariance matrix P t/t _, using
• Step 3 Extract the predicted rate covariance matrix V t/t _, from P 4/Jt _, .
• Step 4 Determine the largest eigenvalue lk _ of V t/t _, .
• Step 5 The rate accuracy without the CORE (Predicted_Test_Nalue) is given by ⁇ k/k _ i .
• Step 1 Obtain the error covariance matrix R k from the CORE.
• Step 4 Extract the filtered rate covariance matrix ⁇ k/k from P t/i .
• Step 6 The rate accuracy with the CORE (Filtered_Test_Value) is given by ⁇ yj ⁇ klk .
• ⁇ LET D Predicted Test Value - Filtered Test Value.
• GRIP is the component that estimates the local sensor's position and the local sensor's angular bias errors. Registration, which is the process of estimating angular bias error, is accomplished by comparing state estimates consisting of unregistered local only data to state estimates consisting of registered remote only data. GRIP accumulates the stream of unregistered AMRs and uses the maneuver detection likelihood output from PACE to develop track state estimates on vehicles that are good candidates for registration. The local track state estimate is compared to the RFACT that CORE Fusion creates by fusing the CORE received from remote platforms. Four levels of registration are performed depending on the data available from remote sources. For the first three levels of registration, the sensors are assumed to have accurate estimates of their own position from GPS measurements and other NAV sources.
• Level 1 registration is performed when the local sensor has measurements on a vehicle that is reporting its GPS measurements as CORE to the TCN network.
• a vehicle is referred to as a reference vehicle.
• the local sensor's RFACT on the reference vehicle may consist of CORE from remote sensor measurements on the reference vehicle but, because the GPS measurements on the vehicle are generally more accurate than sensor measurements, CORE developed from the reference vehicle's GPS data will dominate the local sensor's RFACT.
• Level 2 registration is performed when the local sensor is receiving CORE on mutually measured vehicles from other sensors that are already registered. If the local sensor's CORE are dominating the FACT on one (or more) of the vehicles and the local sensor's RFACT error becomes large, then the distribution of remote CORE may be induced by changing the reporting need on the track or raising the local STAR thresholds.
• Level 3 registration is performed when the local sensor is unregistered and is not receiving CORE on mutually measured vehicles from registered sources. This situation occurs when TCN is first turned on and there are no reference vehicles in the network that are contributing CORE based on ownship position data. In order to obtain accurate initial bias estimates, the unregistered sensors must exchange data on mutually measured vehicles without corrupting the network FACT states with unregistered data.
• a simple implementation, outlined below, to initialize GRIP is to use the existing DC algorithms to exchange unregistered CORE.
• Unregistered CORE are formed initially with ACE and exchanged by the DC because the FACT does not exist.
• CORE Fusion fuses unregistered CORE with the RFACT but not with the FACT.
• An initial bias estimate may be obtained with the first unregistered CORE that is received for a mutually measured vehicle.
• ACE receives a registered AMR for the first time, it reinitializes its state estimate so that the unregistered data in the current state estimate is not exchanged as registered data.
• CORE Fusion fuses subsequent registered CORE with the FACT and reinitializes the RFACT. Then, after the sensors are registered, both the FACT and the RFACT are uncorrupted by unregistered data. In the transition from exchanging unregistered data to registered data, valuable track state data may be lost in ACE unless AMRs received prior to the initial bias estimate are corrected and refiltered. More importantly, though, the RFACT used in the initial bias estimate is formed from a single CORE that was itself formed from two measurements, the minimum number required to send out a CORE. Thus, the RFACT is not a very accurate state estimate from which to register and initial errors in the bias estimate are propagated to the state estimates and some delay is incurred before the system converges to the true bias estimate and state estimates.
• the registration CORE is exchanged with other unregistered sensors that are also measuring the vehicle and can contribute in the dimension of the angular bias error. Since more than two AMRs are used to develop the registration CORE, exchanging registration CORE reduces the variance on the initial bias estimate, which settles the bias estimates more quickly. The bias variance in the angular dimensions is overestimated in the registration CORE so that the dimension of uncertainty is clearly identified for other sensors using the registration CORE.
• Level 4 registration is performed when the local sensor does not have GPS but it does have CORE from registered sensors for vehicles that the local sensor is measuring.
• the local sensor's translational biases are estimated along with its angular biases using local data sources and remote CORE from registered sensors that do have GPS.
• the angular biases are estimated by comparing the differences in the angular dimension between the local track state estimates and the RFACT estimates relative to the local sensor's tangent plane.
• the sensor's GRIP processor has an estimate of the sensor location and has received uncorrected AMRs on the vehicle.
• the sensor's CORE Fusion has received one or more registered CORE on the vehicle from a remote location and formed an RFACT on the vehicle.
• GRLP initializes and updates a local track state estimate of the vehicle with the uncorrected AMRs.
• Both the local track state and the RFACT, maintained in WGS-84 Cartesian, are converted to Cartesian coordinates in the local sensor's tangent plane. Assuming the time of the RFACT is prior to the time of the local state estimate, the RFACT is extrapolated to the time of the local track state estimate.
• the sensor's bearing bias is estimated as the difference between the bearing of the local estimate and the bearing of the RFACT relative to the local sensor's tangent plane.
• the bias variance is the sum of the bearing error of the local estimate and the bearing error of the RFACT. Note that the bearing error of both the local and remote state estimates include the error accumulated by using the local sensor's geodetic location to convert the state estimates into the local sensor's tangent plane.
• the remote CORE could have been received from either a reference vehicle reporting its own GPS location or another sensor with measurements on the mutual vehicle.
• the reference vehicle filters the GPS measurements of its ownship position and sends the measurements out as CORE according to TCN doctrine.
• CORE Fusion forms the RFACT with remote CORE and excludes local CORE so that the RFACT is not conelated with the local state estimate of the vehicle.
• GRIP also filters the GPS measurements of the sensor's location.
• the estimated error of a sensor's location should be included in covariance transformations to and from the sensor's local frame of reference.
• a sensor is said to have GPS if it has current GPS measurements of its own location. Whenever GPS measurements are temporarily unavailable, the navigational biases of the sensor's location must be estimated. In the model, it seems reasonable to simulate the GPS measurements by filtering the estimate of the sensor's position in WGS-84 Cartesian and then converting the estimate to geodetic for (lat, Ion, alt) coordinates rather than filter in geodetic coordinates. In practice, however, other NAV sources should be included in the sensor's location estimate and the filter coordinate frame may depend on the available GPS receiver. In the simulation, the sensor GPS measurements are not filtered; however, for a more accurate representation of the system, they should be. The sensor GPS measurements should not be sent out as CORE unless the sensor is a reference vehicle in the DCN network.
• the bias estimates of the sensors in a network improve as more sensors in the network have more tracks in common. If multiple sensors have measurements on a vehicle, then the sensor with the best geometry with respect to the vehicle and the other sensors should be contributing more data to the FACT and, consequently, more data to the RFACTs of the other sensors.
• each sensor's GRIP processor has a bias estimate associated with each of its track state estimates. Each sensor's bias estimate is a weighted sum of the bias estimates associated with each of its track state estimates.
• Level 1 registration will in general provide more accurate bias estimates than Level 2 registration.
• Bias estimates on vehicles from any level of registration are weighted together so that the more accurate bias estimates are weighted more heavily than the less accurate estimates.
• the bias weighting is described more fully in the algorithm description. Though not implemented in the simulation, the sensor bias should be maintained for immediate use rather than calculating the bias upon receipt of a query. After each sensor measurement is processed and the bias for that vehicle estimated, the old contribution of that vehicle can be subtracted from the weighted sensor bias and variance and the new contribution of that vehicle added.
• the GRIP processor estimates the vehicle track states with a Converted Measurement Kalman Filter that approximates curved trajectories with linear trajectories.
• the vehicles are tracked over fairly long periods of time without resetting the filter.
• the errors in the linear approximations can accumulate and the effects of the accumulated errors can be noticeable, depending on the q-value selection of the GRIP local state filter.
• the pseudo-acceleration caused by the curvature of the earth may be accounted for in the linear Kalman filter.
• the error from the curvature of the earth is absorbed as white noise in the filter processing.
• bias estimate obtained from data on a maneuvering vehicle is likely to be inaccurate, only bias estimates which are likely to have been calculated from data prior to the onset of a maneuver should be used to conect the unaligned AMR stream.
• PACE outputs a flag indicating the number of consecutive measurement residuals that have failed the maneuver test hypothesis. As this number increases, the more likely it is that a maneuver began near the time of the first measurement in the sequence of failures. Any bias estimates using that first measurement or any measurements since then should not be used to conect the AMR stream until the possibility of a maneuver is eliminated. Thus, a history of bias estimates is stored and the most accurate bias estimate is used in correcting the AMR stream.
• bias calculations using the current state estimate are suspended until the vehicle is no longer maneuvering. While bias calculations are suspended, the maneuver can be estimated with a high q-value in the filter equations. There may be lags that appear in the bias estimates; however, if the lag in the local state and the lag in the RFACT are approximately the same, the bias can still be estimated accurately.
• a local state estimate on the vehicle from a time prior to the onset of the maneuver is used to estimate the bias.
• the q-values selected for GRIP an slightly different than for ACE due to the differing goals of the components.
• the bias estimate obtained when the sensor and vehicle geometry was near 90° is more accurate than the bias estimate obtained when the sensors and vehicle are aligned.
• the bias obtained during a period of good geometry should be used during periods of poor geometry.
• old data should be discarded since the bias could change periodically or be slowly varying.
• the most accurate state within a recent time interval should be used to estimate the bias, i.e. for registration purposes the most recent data is not necessarily the most accurate data.
• the most accurate bias estimate will be the one following an update to the RFACT, i.e.
• the state is most accurate. Thus, it may be more practical to update the local GRIP filter each time an AMR is received but only update the bias estimate when an RFACT update is received. Since the bias estimate should be updated regularly, the RFACT should also be updated regularly using adjustments to the reporting need on the track and the STAR thresholds that will induce other sensors to report on the track.
• Updated matrix of bias estimates 5. Updated row indicator.
• the CORE Synthesis component receives COREs from both Sensor Data Conditioners (SDCs) and Link Data Conditioners (LDCs).
• CORE Synthesis is responsible for maintaining three composite track state estimates that are distributed within the local segment.
• the first called the Fusion Algorithm Combined Track (FACT)
• FACT Fusion Algorithm Combined Track
• RFACT Remote FACT
• AFACT Alignment FACT
• FACT estimates are 6 or 9 states.
• Table 2 outlines how the FACT is updated as a function of the number of states in each estimate .
• the H matrix depends on the number of states in both the FACT and the CORE estimate; the following are the H matrices for each of the cases.
• the new FACT estimate is computed using the following least squares technique.
• Time_Lirr.it and UpdateJLimit are predefined constants that determine when a FACT state will be changed from maneuvering to non-maneuvering.
• Time_Limit refers to the time since the last update by a maneuvering CORE and Update Limit refers to the number of consecutive non-maneuvering received.
• Time_Since_Last_Hi_Q CORE Time.
• Time_Since_Last_Hi_Q does not change.

Priority Applications (1)

Applications Claiming Priority (2)

Publications (1)

Family

ID=23909628

Family Applications (1)

Country Status (3)

Cited By (6)

Families Citing this family (72)

Citations (2)

Family Cites Families (3)

• 2000
  • 2000-01-11 US US09/480,859 patent/US6338011B1/en not_active Expired - Lifetime
• 2001
  • 2001-01-11 WO PCT/US2001/000813 patent/WO2001052218A1/en active Application Filing
  • 2001-01-11 AU AU2001229343A patent/AU2001229343A1/en not_active Abandoned

Patent Citations (2)

Non-Patent Citations (2)

Also Published As

Similar Documents

Legal Events