Patent Description:
Safety critical elements in automotive applications have an associated Automotive Safety Integrity Level (ASIL) rating, linked to the acceptable probability of failure of the element that is capable of creating a risk for the vehicle, its driver, or the environment. Today's vehicles have many such ASIL rated elements that communicate parameters between each other. Emerging automotive applications such as an automated driving system (ADS) and an advanced driver assistance system (ADAS) require the absolute position and related values (velocity, heading of motion, time measurements) to be ASIL rated. However, the GNSS position and related values, which are calculated/obtained based on signals received from GNSS satellites, are difficult to validate such that they can be used by ASIL rated systems due to the large number of error sources that may affect the signals received from the GNSS satellites.

The inventive system and method provides an Automotive Safety Integrity Level (ASIL) qualifier for Global Navigation Satellite System (GNSS) position and related values. Specifically, hardware platform diagnostics are executed on the one or more platforms associated with a GNSS Position Sensor (GNSSPS) that calculates/obtains the position and/or related values. In addition, a Receiver Autonomous Integrity Monitoring (RAIM) algorithm is executed on the position and/or related values. The execution of the RAIM algorithm includes a fault detection and exclusion (FDE) component and the computation of a protection level. If the results of the execution of the hardware platform diagnostics and the RAIM algorithm both produce a "good" qualifier, the position and/or related values are assigned an overall qualifier indicating the suitability of the output for use in an ASIL rated system, referend to herein as an ASIL qualifier of "good. " As such, the position and/or related values are deemed valid and may be utilized by the ASIL rated system, such as an automated driving system (ADS) or an advanced driver assistance system (ADAS). However, if either of the qualifiers is a "bad" qualifier, the position and/or related values are assigned an ASIL qualifier of "bad. " As such, the position and/or related values are deemed invalid and cannot be utilized by the ASIL rated system. Advantageously, it can be determined whether the calculated/obtained position and/or related values may be utilized by the ASIL rated system.

In addition, the inventive system and method computes a probability associated with an integrity violation of the RAIM algorithm. Specifically, a fault tree may be utilized to compute the probability that the true error exceeds the protection level computed for the RAIM algorithm. The computed probability is then utilized as input for the hardware platform diagnostics. The inventive system and method may compute the probability that the true error exceeds the protection level computed for the RAIM algorithm utilizing a fault tree that also considers the impact of one or more hardware platform failures. Regardless of the way in which the error probabilities are combined, the resulting overall probability may then be compared to the requirements of the ASIL rating assigned to the system (e.g., A, B, C, or D) to then determine if the system satisfies the requirements of the assigned ASIL rating.

The description below refers to the accompanying drawings, of which:.

Referring to <FIG>, a system <NUM> includes a vehicle <NUM> that includes a sub-system <NUM>, such as an automated driving system (ADS) or an advanced driver assistance system (ADAS), and a vehicle communication network <NUM>. The sub-system <NUM> includes an Electronic Control Unit (ECU) <NUM> and an antenna <NUM>. The ECU <NUM>, which is coupled to the antenna <NUM>, includes a Global Navigation Satellite System Position Sensor (GNSSPS) <NUM> and an ECU platform <NUM>. The GNSSPS <NUM> includes a GNSS safety sub-system <NUM> and a GNSS platform <NUM>. In an embodiment, the sub-system <NUM> is required to comply with a safety standard, such as, but not limited to, the Automotive Road Vehicles-Functional Safety Standard ISO <NUM> that provides requirements for validation and confirmation measures to ensure a sufficient and acceptable level of safety is being achieved. In addition, ISO <NUM> defines the Automotive Safety Integrity Level (ASIL) that is a risk classification scheme that helps define the safety requirements. In order to receive a particular ASIL rating, the system must meet the requirements of that particular ASIL rating (e.g., ASIL B).

The antenna <NUM> receives one or more GNSS satellite signals from one or more GNSS satellites <NUM>. The GNSSPS <NUM> calculates the absolute position based on the timing of ranging codes and carrier signals in the satellite signals received at the antenna <NUM>, as known by those skilled in the art. Further, the GNSSPS <NUM> may calculate or obtain other related values, such as, but not limited to, velocity, heading of motion, and/or time measurements that may be provided to a sensor fusion sub-system (not shown) of the sub-system <NUM>, as known by those skilled in the art. In addition, the GNSSPS <NUM> may obtain and provide range measurements (pseudorange, carrier phase) and ephemeris information to support a tightly or deeply coupled Inertial Navigation System (INS) (not shown) implementation in the sensor fusion sub-system (not shown).

The ECU <NUM> is configured to interface with the vehicle communication network <NUM>. Further, the GNSS safety sub-system <NUM>, of the ECU <NUM>, includes processing logic that is configured to implement one or more embodiments as described herein. Specifically, the GNSS safety sub-system <NUM> may assign an ASIL qualifier to the output of the GNSSPS <NUM> based on execution of hardware platform diagnostics and the RAIM algorithm as described in further detail below. In addition, and as described in further detail below, the ECU platform <NUM> and GNSS platform <NUM> may execute platform specific diagnostics (e.g., hardware and software) that are utilized to implement one or more embodiments described herein.

<FIG> is an exemplary flow chart of the operation of the system and method for assigning an ASIL qualifier to the output of the GNSSPS. The procedure <NUM> starts at step <NUM> and continues to steps <NUM> and <NUM> to respectively implement the hardware platform diagnostic and the RAIM algorithm. Specifically, the hardware platform diagnostic and the RAIM algorithm may be implemented in parallel. More specifically, the hardware platform diagnostic, consisting of GNSS and ECU platform diagnostics, may be implemented continuously, while the RAIM algorithm may be implemented when the GNSSPS <NUM> calculates a particular value (e.g., absolute position) to be potentially utilized by sub-system <NUM> that is an ADS or an ADAS.

At step <NUM>, one or more hardware platform diagnostics are executed on the GNSS platform <NUM> and ECU platform <NUM> of the GNSSPS <NUM> that obtains the data (e.g., absolute position). The hardware platform diagnostics may be executed by the GNSS platform <NUM> and ECU platform <NUM> to protect against hardware failures or "soft" errors, which could affect position and/or related values or the range measurements and ephemeris output by the GNSSPS <NUM>. For example, the hardware platform diagnostics may include, but are not limited to, random access memory (RAM) tests, central processing unit (CPU) register tests, program flow monitoring device readbacks, etc., as known by those skilled in the art. It is noted that the hardware Failure Modes, Effects and Diagnostics analysis (FMEDA) may be utilized to determine which hardware diagnostics are executed by the GNSS platform <NUM> and ECU platform <NUM>.

The procedure continues to step <NUM> and a hardware platform diagnostic qualifier is assigned to the hardware platform, including the GNSS platform <NUM> and ECU platform <NUM>, based on the execution of the hardware platform diagnostics. For example, if the GNSS platform <NUM> and ECU platform <NUM> pass the one or more hardware platform diagnostics, the GNSS safety sub-system <NUM> may assign a qualifier of "good" as the hardware platform diagnostic qualifier. However, if the GNSS platform <NUM> or ECU platform <NUM> fails at least one hardware platform diagnostics, the GNSS safety sub-system <NUM> may assign a qualifier of "bad" as the hardware platform diagnostic qualifier.

At step <NUM>, an absolute position is calculated that is utilized for execution of the RAIM algorithm. Specifically, the GNSSPS <NUM> calculates an absolute position based on the GNSS satellite signals received at the antenna <NUM>. The procedure continues to step <NUM> where the fault detection and exclusion (FDE) component of the RAIM algorithm is executed to determine whether the calculated absolute position contains a faulty measurement. Specifically, the GNSS safety sub-system <NUM> executes the FDE component of the RAIM algorithm to identify cases where there is a faulty measurement, as known by those skilled in the art. For example, a statistical test may be performed on the residuals of the calculated absolute position. In the absence of faulty measurements, the quadratic form of the residual vector follows a chi-squared distribution with a number of degrees of freedom equal to the observations minus the unknown, as known by those skilled in the art. Therefore, a threshold may be set for a given probability of "false alarms," and if the test statistic exceeds the threshold, the solution is considered to contain a faulty measurement.

When it is determined that the calculated absolute position contains a faulty measurement at step <NUM>, the procedure continues to step <NUM> and a faulty measurement is identified and excluded, as known by those skilled in the art. For example, the measurement with the greatest normalized residual may be the measurement selected to be excluded by the GNSS safety sub-system <NUM>. The procedure continues to step <NUM> and it is determined if sufficient measurements remain to calculate the absolute position again. If sufficient measurements remain, the procedure continues to step <NUM> and the absolute position is calculated again and the procedure continues until all faulty measurements, capable of being detected, are excluded. If sufficient measurements do not remain to calculate the absolute position, the procedure continues to step <NUM> and the GNSS safety sub-system <NUM> assigns a qualifier of "bad" as the position qualifier for the absolute position.

When it is determined that the calculated absolute position does not contain a faulty measurement at step <NUM>, the procedure continues to step <NUM> and a protection level is computed for the calculated absolute position that is free of detectable faulty measurements. Illustratively, the GNSS safety sub-system <NUM> computes the protection level. The protection level, as known by those skilled in the art, is an estimate of the maximum error potentially present in the calculated absolute position from undetectable faulty measurements. It is noted that the protection level may be specified separately for a horizontal component (i.e., horizontal protection level) and a vertical component (i.e., vertical protection level). For example, and as known by those skilled in the art, the protection level may be computed as the projection into the position domain of the largest measurement bias which is undetectable by a statistical test on the residuals, as described above with respect to step <NUM>. The projection is made assuming the bias is on the measurement which most strongly impacts the position at a given epoch.

The procedure continues to step <NUM> and it is determined if the protection level exceeds an alert limit. Specifically, the GNSS safety sub-system <NUM> compares the protection level to the alert limit, wherein the protection level and alert limit may both be on the order of centimeters (cm), meters (m), or some other unit of measure. In an embodiment, the alert limit is a parameter of the system design and may be set at a maximum position error that sub-system <NUM> can tolerate. For example, if the absolute position is being utilized for automated parking that requires accuracy on the level of cms, the alert limit may be set to <NUM>, <NUM>, or some other accuracy value. However, if the absolute position is being utilized in conjunction with a map to determine which road the vehicle <NUM> is traveling on, the alert limit may be set to <NUM>, <NUM>, or some other accuracy value. That is, the alert limit may be selected based on how the output of the GNSSPS <NUM> is to be utilized by the sub-system <NUM>.

If at step <NUM> it is determined that the protection level does not exceed the alert limit, the procedure continues to step <NUM> and a qualifier of "good" is assigned as the position qualifier for the calculated absolute position. Specifically, the GNSS safety sub-system <NUM> may assign the qualifier of "good" as the position qualifier. <FIG> illustrates the protection level not exceeding the alert limit. Specifically, the calculated absolute position at <NUM> is utilized to calculate the protection level that is represented as a dashed circle <NUM> having a radius equal to the maximum possible error. The solid circle <NUM> represents the alert limit indicating the maximum position error the sub-system <NUM> can tolerate. As can be seen in <FIG>, the dashed circle <NUM> representing the protection level does not exceed the solid circle <NUM> representing the alert limit.

If at step <NUM> the protection level exceeds the alert limit, the procedure continues to step <NUM> and the GNSS safety sub-system <NUM> assigns a qualifier of "bad" as the position qualifier for the calculated absolute position. <FIG> illustrates the protection level exceeding the alert limit. Specifically, the calculated absolute position at <NUM> is utilized to calculate the protection level that is represented as a dashed circle <NUM> having a radius equal to the maximum possible error. The solid circle <NUM> represents the alert limit indicating the maximum position error the sub-system <NUM> can tolerate. As can be seen in <FIG>, the dashed circle <NUM> representing the protection level exceeds the solid circle <NUM> representing the alert limit.

After a hardware platform diagnostic qualifier and a position qualifier have both been assigned, the procedure continues to step <NUM>, and it is determined if both assigned qualifiers are "good. " If at step <NUM> it is determined that both assigned qualifiers are "good," the procedure continues to step <NUM> and a qualifier of "good" is assigned as the ASIL qualifier indicating that the absolute position is valid and can be utilized by the sub-system <NUM>. However, if at step <NUM> it is determined that either of the qualifiers is "bad," the procedure continues to step <NUM> and a qualifier of "bad" is assigned as the ASIL qualifier indicating that the absolute position is invalid and cannot be utilized by the sub-system <NUM>. At step <NUM>, the procedure ends.

Although the example as discussed with reference to <FIG> describes assigning an ASIL qualifier for the absolute position calculated by the GNSSPS <NUM>, it is expressly contemplated that other related values, such as, but not limited velocity, heading of motion, and/or time measurements may be assigned an ASIL qualifier in a similar manner as described above. In addition or alternatively, the range measurements (pseudorange, carrier phase) and ephemeris information obtained by the GNSSPS <NUM> may be assigned an ASIL qualifier in a similar manner as described above. Specifically, the hardware platform diagnostics and the RAIM algorithm may be executed as described above to assign an ASIL qualifier to the other related values.

<FIG> shows a simplified example of a fault tree <NUM> utilized for computing a probability associated with an integrity violation of the RAIM according to one or more embodiments described herein. As described herein, an integrity violation occurs when the true error exceeds the computed protection level for the RAIM algorithm. As depicted in <FIG>, the fault tree <NUM> includes a plurality of nodes <NUM>, where each node is associated with a failure from a different source. Within each node <NUM> is a value representing the probability of the failure from the different source. For example and with reference to <FIG>, the probability that a fault was not detected by the RAIM algorithm is. In addition, the probability of an unexpected error on one or more GNSS measurements, such as single satellite fault and an anomalous atmospheric delay, are respectively. <NUM>% and. Therefore, the probability of an error in the solution is. The probabilities as depicted in <FIG> are for illustratively purposes only and may be derived in a variety of ways as known by those skilled in the art.

Therefore, and based on the particular sources of failures and their probabilities as depicted in <FIG>, the probability of an integrity violation, e.g., that the true error exceeds the computed protection level, is. The output probability of an integrity violation, in this example. <NUM>% , may then be utilized as input to the analysis of the hardware failure rate, e.g., an FMEDA. This analysis provides the evidence that the output of the GNSSPS <NUM> meets the requirements of the assigned ASIL rating. Additionally, this analysis is used to identify the hardware platform diagnostics which are to be executed at step <NUM> of <FIG>. Specifically, the output probability, which represents the integrity risk of the RAIM algorithm, may be included as input to the hardware platform analysis to guarantee satisfaction of the requirements of the ASIL rated sub-system <NUM>. In addition, although <FIG> depicts the sources of the failures being from a fault not being detected by the RAIM algorithm, a single satellite fault, and an anomalous atmospheric delay, it is expressly contemplated that any of a variety of different/additional sources may be utilized in the fault tree as depicted in <FIG>.

<FIG> shows a simplified example of a fault tree <NUM>, that considers the impact of one or more hardware platform failures, utilized for computing a probability associated with an integrity violation of the RAIM algorithm according to one or more embodiments described herein. The fault tree <NUM> includes the failure from the different source as depicted in <FIG> but also includes the impact of the one or more hardware platform failures. Failure of the hardware platform can contribute to the integrity risk in a variety of ways. For example, a hardware platform failure might lead directly to an error in a measurement, e.g., in the case of a memory soft error affecting a stored value. In addition or alternatively, a hardware platform failure may cause incorrect operation of the RAIM algorithm, causing it to fail to detect an error which would have otherwise been detected, e.g., through incorrect program flow.

As depicted in <FIG>, the fault tree <NUM> includes a plurality of nodes <NUM>, where each node is associated with a failure from a different source that includes potential hardware platform failures. Each node <NUM> includes a value representing the probability of the failure from the different source. For example and with reference to <FIG>, the probability that the RAIM algorithm was unable to detect a fault is. In addition, the probability of an unexpected error on one or more GNSS measurements, such as single satellite fault and an anomalous atmospheric delay, are respectively. <NUM>% and. Further, the probability of a hardware platform fault that affects the operation of the RAIM algorithm is. <NUM>% and the probability that a hardware platform fault biases a measurement is. Therefore, the probability of an error in the solution, that includes the impact of potential hardware platform failures, is. In addition, the probability that the fault is not detected by the RAIM algorithm, that includes the impact of potential hardware platform failures, is.

Therefore, and based on the particular sources of failures and their probabilities as depicted in <FIG> that includes the impact of potential hardware platform failures, the probability of an integrity violation, e.g., that the true error exceeds the computed protection level, is. The computed probability may be compared with the requirements of the ASIL rating (e.g., A, B, C, or D) assigned to the sub-system <NUM> to determine if the system meets the requirements of the assigned ASIL rating. For example, if the computed probability meets the requirements of the ASIL rating of B, the sub-system <NUM> may be determined to comply with an ASIL rating of B. However, if the computed probability meets the requirements of the ASIL rating of D, the sub-system <NUM> may be determined to comply with an ASIL rating of D. Although <FIG> depicts particular sources of failures, it is expressly contemplated that any of a variety of different/additional sources may be utilized in the fault tree as depicted in <FIG>.

Claim 1:
A system (<NUM>) comprising:
a GNSS position sensor (<NUM>) configured to calculate or obtain data based on signals received from GNSS satellites (<NUM>), wherein the data comprises one of an absolute position, velocity, heading of motion, or time measurements; one or more processors configured to:
execute (<NUM>) one or more hardware platform diagnostics on one or more platforms (<NUM>, <NUM>) associated with the GNSS position sensor (<NUM>) to determine if the one or more platforms (<NUM>, <NUM>) pass or fail the one or more hardware platform diagnostics,
assign (<NUM>) a hardware platform good qualifier as a hardware platform qualifier for the one or more platforms associated with the GNSS position sensor (<NUM>) when all of the one or more hardware platform diagnostics pass and assign (<NUM>) a hardware platform bad qualifier as the hardware platform qualifier for the one or more platforms (<NUM>, <NUM>) associated with the GNSS position sensor (<NUM>) when at least one of the one or more hardware platform diagnostics fails,
execute a RAIM algorithm to compute (<NUM>) at least a protection level for the data,
assign (<NUM>) an output good qualifier as an output qualifier for the data when the protection level does not exceed an alert limit and assign (<NUM>) an output bad qualifier as the output qualifier for the data when the protection level exceeds the alert limit,
assign (<NUM>) an Automotive Safety Integrity Level (ASIL) good qualifier as an ASIL qualifier when the output qualifier is assigned the output good qualifier and the hardware platform qualifier is assigned the hardware platform good qualifier, wherein the ASIL good qualifier is an indication that the data can be utilized,
assign (<NUM>) an ASIL bad qualifier as the ASIL qualifier when the output qualifier is assigned the output bad qualifier or the hardware platform qualifier is assigned the hardware platform bad qualifier, wherein ASIL bad qualifier is an indication that the data should not be utilized, and
compute a probability associated with an integrity violation of the RAIM algorithm, wherein the integrity violation occurs when a true error exceeds the computed protection level for the RAIM algorithm and the computed probability associated with the integrity violation of the RAIM algorithm is utilized as input for the hardware platform diagnostics.