Safe GNSS positioning

Safe and reliable positioning solutions powered by u-blox safety engineered GNSS products.

Safety is a core differentiator for positioning solutions that operate in safety‑critical environments such as automotive and agricultural automation. This technology page summarizes why safety matters, what safety engineering means in practice, and how safety considerations translate into the development and validation of safe GNSS products and related subsystems.

Why safety matters

Safety is not an abstract compliance topic and not only a tick mark to comply with legal and regulatory frameworks. It is problem-oriented, use-case driven aspect that requires consideration along the whole product development lifecycle to:

• Prevent and control potential hazards: GNSS output may be used as an input to control or decision functions where incorrect position, velocity, attitude or time can lead to hazardous behavior.
• Ensure product liability: Safety related claims, foreseeable misuse, and failure modes must be addressed with evidence and traceable engineering artifacts.
• Avoid reputation damage: Safety incidents can have long lasting impact on customer trust, partner relationships, and brand perception.

Consider these examples of GNSS in automotive and agriculture safety:

• Lane-level localization is crucial for advanced driver assistance systems (ADAS) and automated driving. A GNSS positioning error may cause a vehicle to veer out of its lane, potentially leading to a collision or violating operational boundaries.
• When GNSS data guides autonomous tractors or robotic sprayers, safety measures help preventing unintended vehicle movements, operation outside field boundaries, or unsafe behavior near people and obstacles—ultimately safeguarding crops, equipment, and human safety.

These examples highlight that safety solutions must be tailored to the specific risks and requirements of each use case, ensuring that protective measures are both relevant and effective. When positioning contributes to decisions or actuation (e.g., vehicle control, automated steering, geofencing, speed limiting, machine guidance), hazards can directly affect people, property, and the environment.

Application areas where safe GNSS is relevant

• Automotive: Safe GNSS is essential for advanced driver assistance systems (ADAS) and automated driving. Reliable, lane-level localization is necessary to avoid accidents caused by lane departures or violations of operational boundaries.
• Agriculture: Autonomous tractors and robotic sprayers depend on safe GNSS for precise operation within field boundaries. Safety measures prevent unintended movements and ensure safe behavior around people and obstacles, protecting crops, assets, and human life. See also: Agriculture safety page.
• Industrial Automation: Safe GNSS enables machines to operate only within safe limits, reducing risks to people, property, and the environment.
• Robotics: Robotic systems leverage safe GNSS to avoid hazardous behavior, ensuring safety in complex and dynamic environments.

How does safety enhance high-precision GNSS?

High-precision GNSS (HPG) focuses on how accurate the position is, while Safe GNSS focuses on how trustworthy and safe the position is under all operating conditions. The different primary objectives might be formulated, such as:

• Primary objective of HPG: Deliver very small positioning errors optimized for accuracy, precision, convergence speed and availability of a high accuracy solution.
• Primary objective of safe GNSS: Ensure that hazardous positioning errors are prevented or signaled in time, even if accuracy degrades. Optimized for integrity (trust in the output), fault detection and diagnostics, controlled behavior under failure or functional insufficiency and compatibility with functional safety and SOTIF arguments.

The different scopes of high precision and safety can be compared as follows:

Aspect	High‑Precision GNSS	Safe GNSS
Main goal	Accuracy	Safety & trust
Typical error	cm–dm	cm–dm (bounded)
Integrity guarantee	No	Yes
Fault handling	Limited	Systematic (fault detection and exclusion, integrity monitoring, diagnostics)
Behavior on failure	Undefined	Defined & safe
Safety standards	Not targeted	ISO 26262, ISO25119, ISO 21448, etc.
Typical use	QM automotive and agriculture, industrial, surveying, robotics	ADAS, autonomy, safety‑critical systems

Safety in u-blox GNSS products

Safety is a system property that is achieved through diligent safety engineering, i.e., identifying hazards, their causal factors, and predicting the resultant severity and probability. A safe GNSS product is designed to provide positioning outputs with appropriate integrity and diagnostics for the targeted safety use case. In practice this means: clearly defined assumptions of use, robust detection of abnormal conditions, and controlled behavior when requirements are violated (e.g., alarming, output limiting, fallback, or safe state).

The UBX-A9940-KA chip and ZED-A20K module are u-blox products which are designed, developed and validated in accordance to relevant quality, safety and security standards following established safety engineering practices.

• The UBX‑A9940‑KA is the u‑blox A9 functionally safe GNSS chip featuring an ISO 26262 ASIL‑B compliant multi-constellation, multi-band measurement engine for GNSS localization.
• ZED‑A20K is designed for mixed-criticality applications and delivers ASIL-B measurements and a high‑performance positioning solution in a single module. It targets advanced automotive applications at automation levels L2+ and beyond, where performance, availability, and functional safety matter.

What does “safety engineering” mean?

Safety engineering is the discipline concerned with ensuring that systems, products, and processes achieve an acceptable level of safety throughout their lifecycle. It identifies hazards, assesses risks, and defines measures to prevent or mitigate accidental harm. Safety engineering concentrates on

• Preventing unreasonable risk
• Anticipating how things can go wrong
• Ensuring safe behavior even when they do

and aims to answer three key questions:

• What could cause harm? (Hazards)
• How could this happen? (Failure modes, functional insufficiencies, misuse)
• What ensures it does not lead to harm? (Safety mechanisms + evidence)

Safety engineering involves methods to systematically identify hazards, derive safety requirements, implement safety mechanisms, and demonstrate (with evidence) that residual risk is acceptable for the intended use. Some established safety analysis methods are for instance:

Method	Purpose / key question	Typical outputs
HARA (Hazard Analysis and Risk Assessment)	What hazards exist in defined operating scenarios, and what risk reduction is needed?	Hazards, risk classification (e.g., S/E/C and ASIL in ISO 26262), safety goals, high‑level safety requirements.
FME(D)A (Failure Modes and Effects Analysis)	How can an item/function fail, what are the effects, and how do we detect/mitigate it?	Failure modes and effects, detection/mitigation actions, safety mechanisms/diagnostics, verification focus.
FTA (Fault Tree Analysis)	How can a top hazardous event occur (including combinations of faults)?	Fault trees, contributing fault combinations, completeness/architecture checks, support for safety case argumentation.

Safety engineered products can handle hazardous situations through fault detection, probabilistic fault exclusion, integrity bounding, and timely failure signalization to ensure that hazardous positioning errors are either mitigated or safely indicated before use. Techniques to handle faults are usually organized as a capability chain covering the following steps

1. Fault detection: Detect abnormal behavior in GNSS measurements or states that could indicate the presence of a fault.
2. Fault identification and isolation: Determine which element(s) are likely faulty once an anomaly is detected.
3. Fault exclusion / mitigation: Prevent detected faulty elements from influencing the position solution.
4. Integrity monitoring and bounding: Quantify how trustworthy the remaining solution is, even after mitigation.
5. User / system failure signalization: Ensure the system reacts safely if integrity cannot be guaranteed.

Each step builds on the previous one and may operate at different hierarchical levels like signal, satellite, constellation, sensor, or position level.

Domains of holistic safety

There are few primary domains which are most relevant to safety:

• Functional Safety (FuSa) focuses on hazards caused by malfunctions (e.g., random hardware failures, systematic faults).
• SOTIF (Safety Of The Intended Functionality) focuses on hazards that can occur without a malfunction, for example due to performance limitations, insufficient sensing, or foreseeable misuse.
• Cybersecurity threats such as jamming/spoofing can trigger unsafe conditions and should be considered in the overall safety argument and concept.

Safety protects against accidental harm caused by system failures, while security protects against intentional harm caused by malicious actions- and both are necessary to achieve trustworthy autonomous and GNSS‑based systems, i.e.,

• A security breach can directly create a safety hazard
• An unsafe behavior may be triggered intentionally

This interdependence is explicitly highlighted in safety‑security co‑engineering approaches where two layers of trustworthiness are taken into account:

• Safety ensures the system behaves safely when things go wrong
• Security ensures things don’t go wrong on purpose

• Quality engineering can be considered a prerequisitefor safety engineering. It ensures that systematic development faults like requirements gaps, design errors, implementation defects or verification gaps won’t become safety issues. Safety activities therefore need strong alignment with the overall development lifecycle and controls (e.g., an ASPICE‑aligned V‑model), ensuring traceability from hazards to requirements, design, implementation, verification, and validation.

All these domains are regulated through international and industry tailored standards.

Safety-related automotive and agriculture standards

Safety is regulated by various regulations, frameworks and standards, often tailored to specific industries. Below is a short scope/purpose summary for essential regulations and standards which are relevant for safe GNSS product development:

🟩 – compliance by u-blox product(s)
🟧 – u-blox product(s) supports OEM/machine-level compliance

Standard / Regulation	Scope (summary)	Relation to u-blox GNSS product	Status
General, cross-industry regulations, frameworks and standards
EU Machinery Regulation 2023/1230	EU legal framework defining essential health and safety requirements and conformity assessment/CE‑marking obligations for machinery and related products, with updates for digital technologies and clarifications such as “substantial modification” and “partly completed machinery.”	GNSS is typically a component; compliance is demonstrated at machine level by the OEM via risk assessment and verification/validation.	🟧
IEC 61508	Generic functional safety standard defining a risk‑based safety lifecycle for hardware/software to achieve risk reduction via Safety Integrity Levels (SIL 1–4); basis for many sector standards.	Applies to the safety function/system, not automatically to a standalone GNSS module; the GNSS can support a SIL claim as a safety-related input with safety manual evidence, while the integrator proves SIL at system level.	🟧
Quality management / Quality engineering
ISO 9001	Quality management system requirements to consistently meet customer and statutory/regulatory requirements (process approach, risk-based thinking, performance evaluation, continual improvement).	All positioning products by u-blox comply with ISO 9001.	🟩
IATF 16949	Automotive-sector quality management standard used with ISO 9001, adding supply-chain expectations focused on defect prevention, reduction of variation and waste, and meeting customer-specific requirements.	All positioning products by u-blox comply with IATF 16949.	🟩
Automotive SPICE® (ASPICE)	Automotive process framework for assessing and improving capability of system & software engineering, management, and support processes for software-based/E/E systems.	A9 and A20 comply with the ASPICE process framework.	🟩
Automotive industry-tailored standards
ISO 26262	Automotive adaptation of IEC 61508 specifying an automotive safety lifecycle and work products to address hazards due to E/E system malfunctions; uses ASIL A–D.	A9 and A20 comply with ISO 26262 ASIL-B(D).	🟩
ISO 21448	Argument framework and guidance to reduce hazards from functional insufficiencies and foreseeable misuse (unsafe behavior without malfunction), complementing ISO 26262.	u-blox positioning products integrate SOTIF support features and support ISO 21448 compliance.	🟧
ISO/SAE 21434	Engineering requirements for cybersecurity risk management across the vehicle E/E lifecycle (incl. TARA) and supporting work products; complementary to functional safety.	A9 complies with ISO 21434.	🟩
Agriculture industry-tailored standards
ISO 13849	Machinery functional safety standard for design/validation of SRP/CS using Categories and Performance Levels (PL a–e) to specify reliability of safety functions.	Applies to machine safety functions, not automatically to a GNSS module; GNSS can support the OEM’s PL target when used as a safety-related input.	🟧
ISO 25119	Sector functional safety standard for agricultural/forestry tractors and machines for safety-related control functions implemented with E/E/PE systems; uses Agriculture Performance Level (AgPL).	A9 and A20 are ISO 26262 compliant up to ASIL‑B and therefore ready to comply with ISO 25119 up to AgPL d.	🟩
ISO 18497	Design principles and guidance (incl. information for use/residual risks) for safety of automated/autonomous agricultural machinery during intended use and foreseeable misuse.	Addressed at automated machine function level; A9/A20 support ISO 18497 compliance via GNSS localization with defined assumptions/limits, integrity/status signaling, and integration guidance for monitoring and safe fallback.	🟧

Safety-related roles and contributions in a GNSS system

The safety role of GNSS cannot be defined in isolation. Instead, it is derived from the application‑level function, safety goals, and operational concept. The safety relevance of GNSS is not intrinsic to the technology itself but derived. GNSS is a means to an end, and its required safety contribution depends entirely on how and where its output is used within the vehicle system. GNSS requirements and integrity expectations are therefore derived top‑down from application‑level hazards, not specified bottom‑up from GNSS capabilities.

Safe positioning does not emerge from a single component, but from the orchestrated interaction of sensing, monitoring, redundancy, and decision logic. A typical GNSS positioning system setup composed of

• GNSS antenna
• Measurement Engine
• GNSS correction service
• Inertial Measurement Unit (IMU)
• Wheel Speed Sensors (WSS)
• Positioning Engine

Each element has its role and safety contribution with relevance in the functional safety, SOTIF or both domains as depicted in Fig. X.

u-blox safe product development lifecycle

A safety‑driven development approach adds specific planning, analysis, and evidence generation on top of “standard” engineering. The objective is to ensure that safety requirements are derived from hazards, implemented with appropriate mechanisms, and verified and validated with traceable work products and documented evidence.

A generic safety‑oriented lifecycle typically includes:

• Safety management: Safety management establishes the organizational framework by defining roles, responsibilities, competencies, and governance to ensure safety activities are planned, executed, and controlled consistently.
• Safety planning: Safety planning defines the scope, milestones, work products, and confirmation measures required to achieve and demonstrate compliance with the applicable safety standards.
• Hazard Analysis & Risk Assessment (HARA): The HARA systematically identifies hazardous scenarios and assigns the integrity targets / required risk reduction (e.g., ASIL/AgPL where applicable) to define safety goals.
• Safety requirements: Safety requirements are documented in an unambiguous and testable form and maintained with bidirectional traceability to hazards, architecture, and verification results.
• Safety concept: The safety concept explains how the safety goals are achieved by architectural measures and mechanisms (detection, mitigation, safe state, fault handling), including assumptions of use and system integration expectations.
• Verification & validation: Verification shows the implementation meets the specified safety requirements, while validation shows the resulting behavior is acceptably safe for the intended use cases and operating scenarios.
• System and safety validation: System-level validation confirms correct interaction across interfaces (including external components and services) and demonstrates that safety performance holds in the integrated configuration.
• Approval and product release: Approval and product release confirm that the safety case is complete and supported by sufficient evidence, enabling a justified decision to release the product for its intended safety‑relevant use.

For A9 and ZED-A20K functionally safe GNSS products developed at u-blox, these activities are integrated into the overall product development lifecycle through established internal safety and quality processes. The corresponding safety deliverables and supporting evidence are created throughout development.

Get in touch for orders or any queries: sales@rfdesign.co.za / +27 21 555 8400

Courtesy of u-blox