A safe automotive Global Navigation Satellite System (GNSS) is not an accurate one, it is an honest one. Safety does not come from a small error; it comes from the receiver bounding its own error and raising an alarm before that bound is breached. That is integrity, and it is why automotive GNSS has to satisfy both International Organization for Standardization (ISO) 26262 (faults) and ISO 21448 Safety Of The Intended Functionality (SOTIF) (the no-fault case), not an accuracy spec.
This is for automotive functional-safety and positioning engineers who already work with Real-Time Kinematic (RTK) or Precise Point Positioning with RTK-style ambiguity resolution (PPP-RTK) and now have to make a position trustworthy enough for an ADAS or automated-driving function.
Accuracy is not integrity
A receiver quoting “5 cm accuracy” is almost always stating a 1-sigma (68%) figure: roughly one fix in three is worse than that, and the tail says nothing about how bad the worst case gets. For a lane-keeping or automated-driving function, the one-in-a-million fix that is 8 m off and looks fine is the one that hurts you. Accuracy describes the good days. Safety is about the bad ones.
The safety question is not “how accurate is it” but “can the system bound its error right now and tell me when it cannot.” Swift Navigation puts the inversion plainly: a centimeter accuracy claim is only a confidence statement, and what matters for safety is whether the system can guarantee the error stays under a limit the application can tolerate. That guarantee is integrity, and it has its own vocabulary.
The integrity vocabulary
Integrity is, in the European Space Agency (ESA) Navipedia definition, the measure of trust you can place in the correctness of the position, including a timely warning when the position is not safe to use. Four quantities make that concrete.
- Protection Level (PL): a statistical bound on the position error, computed in real time, such that the probability of the true error exceeding it is no larger than the target integrity risk. It is the receiver’s honest estimate of its own worst case right now.
- Alert Limit (AL): the largest position error the application can tolerate before it is hazardous. For a road function this is a property of the use case, not the receiver.
- Integrity Risk (IR): the probability that the error exceeds the alert limit without the system alerting you. Automotive targets are demanding; Swift Navigation cites figures as low as 10^-7 per hour for the target integrity risk.
- Time To Alert (TTA): the maximum time from the position going out of tolerance to the system raising the alarm. On the road this is on the order of a second, far tighter than aviation’s.
The decision logic is one line: if PL < AL, trust the position; if PL >= AL, alert and degrade. A system that does this is not promising it is always accurate. It is promising it will tell you when it is not.
Misleading vs hazardously misleading information
Two failure states matter, and the Stanford diagram is the canonical way to see them. Plot the receiver’s predicted error (the protection level) against the actual error. Misleading Information (MI) is when the actual error exceeds the protection level but is still below the alert limit: the receiver underestimated itself, but you are not yet in danger. Hazardously Misleading Information (HMI) is the one that kills: actual error exceeds the alert limit while the system still reports the fix as usable. Integrity engineering exists to drive the probability of HMI below the target integrity risk. If you take one diagram into a design review, take that one (Focal Point and ESA Navipedia both lay it out).
The road domain demands tighter alert limits and a roughly one-second time-to-alert, far less forgiving than the aviation integrity concepts it borrows from. Photo by 蔡宗翰 on Pexels.
Why ISO 26262 is not enough
Two standards apply, and they cover different failures.
ISO 26262 is functional safety for electrical and electronic systems: it addresses malfunctions, the random hardware faults and systematic software bugs in the receiver and its electrical and electronic (E/E) context. It assigns an Automotive Safety Integrity Level (ASIL) and demands the development rigor to match.
ISO 21448 (SOTIF) addresses the case where nothing is broken and the function is still unsafe because its performance is insufficient for the situation. This is exactly where GNSS lives. Multipath in an urban canyon, an ionospheric scintillation event, an unflagged jammer or spoofer: none of these is a component fault, yet each can hand the fusion engine a confident, wrong position. A receiver can pass every ISO 26262 fault test and still produce hazardously misleading information, because the hazard was never a malfunction.
| ISO 26262 | ISO 21448 (SOTIF) | |
|---|---|---|
| Scope | E/E system malfunctions | Insufficiency of the intended function |
| Failure type | Random HW faults, systematic SW faults | Performance limitation, no fault present |
| GNSS example | Receiver chip fault, firmware bug | Multipath, ionosphere, jamming or spoofing |
| What it asks | Build it without faults, to an ASIL | Prove the function is adequate across the operating domain |
The takeaway: an automotive GNSS function needs both. ISO 26262 makes the box trustworthy; SOTIF makes the position trustworthy in the messy real world. Treating GNSS safety as an ISO 26262 checkbox is the most common and most dangerous shortcut.
What ASIL does an automotive GNSS engine need?
It depends on the function it feeds and how the safety goal is decomposed, but positioning that supports automated driving is commonly allocated a high ASIL, often expressed as something like ASIL-B(D) after decomposition, where a stringent ASIL-D goal is split across redundant, independent channels. The receiver and its integrity monitor are one channel; cross-checks from inertial, odometry and map are others.
The road domain inherits its integrity math from aviation (the DO-229 Satellite-Based Augmentation System (SBAS) lineage), then tightens it. Where aviation tolerates alert limits of tens of meters and a time-to-alert of several seconds, automotive alert limits land around 0.5 to 3 m with a time-to-alert near one second (Swift Navigation’s worked example uses a 2 m alert limit). Same framework, an order of magnitude less room.
Specifying a safety GNSS requirement
Pulling it together, a safety positioning requirement is not “5 cm.” It is a tuple:
- An alert limit from the function (for example, stay within the lane: roughly 1 to 2 m lateral).
- A target integrity risk and time to alert from the safety case (for example, 10^-7 per hour, 1 s).
- A live protection level the receiver must compute and keep below the alert limit, or else flag the fix unavailable.
Accuracy still matters, because the protection level cannot be smaller than the error: standalone GNSS at 3 to 10 m cannot bound a 2 m alert limit, which is why RTK, Precise Point Positioning (PPP) or PPP-RTK corrections (delivered as Observation Space Representation (OSR) or State Space Representation (SSR) streams, standardized for cellular delivery in 3rd Generation Partnership Project (3GPP) Release 17) are the enabler that integrity is layered on top of. Corrections buy you the accuracy headroom; integrity monitoring turns that headroom into a guarantee. Neither alone is safe.
Key takeaways:
- Accuracy is not integrity. A spec-sheet accuracy figure describes the good fixes; safety depends on the receiver bounding its own error in real time and alerting when it cannot.
- Four quantities define the safety case. Protection Level (PL), Alert Limit (AL), Integrity Risk (IR) and Time To Alert (TTA) turn integrity into a testable decision: trust the fix only when the protection level stays below the alert limit.
- ISO 26262 alone is not enough. It covers malfunctions, but GNSS hazards like multipath, ionosphere and jamming are no-fault performance limitations that fall under ISO 21448 (SOTIF), so a position needs both.
- The Advanced Driver-Assistance Systems (ADAS) domain inherits aviation integrity math, then tightens it. Automotive alert limits land near 0.5 to 3 m with a roughly one-second time-to-alert, an order of magnitude less room than aviation.
- A safety requirement is a tuple, not a number. It pairs an alert limit, a target integrity risk and a time-to-alert with a live protection level the receiver must compute and police.
Frequently asked questions
What is the difference between GNSS accuracy and GNSS integrity?
Accuracy is how close a typical fix is to truth, usually quoted at 1-sigma (68%). Integrity is the trust you can place in the fix: the receiver bounds its own error with a protection level and alerts you within a fixed time if that bound is breached. A system can be accurate on average and still unsafe if it cannot detect and flag its rare large errors.
What is a GNSS protection level, and how is it different from the alert limit?
The protection level is a real-time statistical bound on the current position error, sized so the probability of the true error exceeding it is below the target integrity risk. The alert limit is the largest error the application can tolerate. The receiver compares them: protection level below alert limit means trust the fix, protection level at or above the alert limit means alert and degrade.
What is target integrity risk for automotive positioning?
Target integrity risk is the maximum acceptable probability that the position error exceeds the alert limit without an alert. It comes from the safety case, not the receiver. Automotive figures are stringent; Swift Navigation cites targets as low as 10^-7 per hour for safety-relevant functions, far tighter than consumer navigation, which has no integrity requirement at all.
What is the difference between ISO 26262 and ISO 21448 (SOTIF)?
ISO 26262 covers malfunctions: random hardware faults and systematic software faults in the E/E system, rated by ASIL. ISO 21448 (SOTIF) covers the case where nothing is broken but the intended function is still insufficient, such as a GNSS receiver producing a confident wrong position from multipath or jamming. GNSS safety needs both, because its worst hazards are SOTIF performance limitations, not component faults.
Why isn’t centimeter RTK accuracy enough for autonomous driving?
Because accuracy describes the typical fix, not the worst one, and RTK can still output a wrong fixed solution under multipath or a wrong ambiguity resolution. Safety needs the system to bound and police its error in real time and to alert within about a second when it cannot, which is integrity monitoring. Accuracy provides the headroom; integrity provides the guarantee.
Does an automotive GNSS receiver need to be ISO 26262 certified?
If it contributes to a safety goal, yes, its development must meet ISO 26262 at the allocated ASIL, and the intended-function performance must be argued under ISO 21448 (SOTIF). The exact ASIL depends on the function and how the safety goal is decomposed across redundant channels. Consumer navigation receivers carry no such obligation, which is why they are not interchangeable with safety positioning engines.
What is hazardously misleading information?
Hazardously misleading information (HMI) is when the position error exceeds the alert limit while the system still reports the fix as usable. It is the failure integrity engineering exists to make extremely improbable. Its less severe cousin, misleading information (MI), is when the error exceeds the protection level but stays under the alert limit. The Stanford diagram maps both against normal and unavailable states.
Sources and further reading
- ESA Navipedia, Integrity: protection level, alert limit, integrity risk, time to alert
- Swift Navigation, Automotive safety through precise GNSS: trust and integrity
- Ericsson, 3GPP GNSS positioning and integrity (Release 17)
- GMV, The role of highly accurate and safe GNSS in automobiles
- Focal Point, The Stanford diagram for GNSS integrity in ADAS
Alert limits, integrity-risk targets and ASIL allocations are use-case and safety-case specific; figures here are representative as of June 2026, not requirements. Derive yours from your own hazard analysis.