安全的GNSS定位

目录

• 为何安全至关重要
• 安全GNSS相关的应用领域
• 安全性如何提升高精度GNSS性能？
• u-blox GNSS 产品中的安全性
• “安全工程”的含义是什么？
• 全面安全涵盖的领域
• 与安全相关的汽车和农业标准
• GNSS系统中与安全相关的角色与贡献
• u-blox 安全产品开发生命周期

对于在汽车和农业自动化等安全关键型环境中运行的定位解决方案而言，安全性是其核心差异化因素。本技术页面总结了安全为何重要、安全工程在实践中的含义，以及如何将安全考量转化为安全GNSS产品及相关子系统的开发与验证。

另请参阅：

为什么安全很重要

安全并非一个抽象的合规议题，也不仅仅是为了满足法律和监管框架而打个勾。它是一个以问题为导向、以用例为驱动的方面，需要在整个产品开发生命周期中加以考虑，以：

• 预防和控制潜在危险：GNSS 输出可能作为控制或决策功能的输入，若位置、速度、姿态或时间信息不准确，可能会导致危险行为。
• 确保产品责任：必须通过证据和可追溯的工程成果，妥善处理与安全相关的索赔、可预见的误用以及故障模式。
• 避免声誉受损：安全事件可能会对客户信任、合作伙伴关系以及品牌形象产生长期影响。

请参考以下 GNSS 在汽车和农业安全领域的应用示例： 

• 车道级定位对于高级驾驶辅助系统（ADAS）和自动驾驶至关重要。GNSS定位误差可能导致车辆偏离车道，从而引发碰撞或越出操作边界。
• 当GNSS数据引导自动驾驶拖拉机或机器人喷雾机时，安全措施有助于防止车辆意外移动、超出田间边界作业，或在人员和障碍物附近出现不安全行为——最终保障作物、设备及人身安全。

这些例子凸显出，安全解决方案必须针对每个用例的具体风险和要求量身定制，以确保防护措施既切合实际又行之有效。当定位数据用于辅助决策或执行操作（例如车辆控制、自动转向、地理围栏、限速、机器引导）时，潜在风险可能会直接危及人员、财产和环境。

安全GNSS适用的应用领域

• 汽车领域：安全GNSS对于高级驾驶辅助系统（ADAS）和自动驾驶至关重要。可靠的车道级定位是避免因偏离车道或违反操作边界而引发事故的必要条件。
• 农业：自动驾驶拖拉机和机器人喷雾机依赖安全GNSS在田间边界内进行精准作业。安全措施可防止意外移动，并确保在人员和障碍物周围保持安全行为，从而保护农作物、资产和人的生命安全。另请参阅：农业安全页面。
• 工业自动化：安全GNSS可确保机器仅在安全范围内运行，从而降低对人员、财产和环境的风险。
• 机器人技术：机器人系统利用安全的GNSS避免危险行为，确保在复杂且动态的环境中安全运行。

安全性如何提升高精度GNSS？

高精度GNSS（HPG）侧重于位置测量的准确性，而安全GNSS则侧重于在所有运行条件下位置测量的可靠性和安全性 。其主要目标可具体表述如下：

• HPG的主要目标：提供定位误差极小的结果，在精度、精确度、收敛速度以及高精度解的可用性方面进行优化。
• 安全GNSS的主要目标：确保即使精度下降，也能及时防止或警示危险的定位误差。优化方向包括：完整性（对输出的可信度）、故障检测与诊断、在故障或功能不足情况下的受控行为，以及与功能安全及SOTIF原则的兼容性。

高精度与安全领域的不同范围可作如下比较：

方面	高精度GNSS	安全GNSS
主要目标	精度	安全与信任
典型误差	cm–dm	厘米–分米（有界）
完整性保证	否	是
故障处理	有限	系统化（故障检测与排除、完整性监控、诊断）
故障时的行为	未定义	已定义且安全
安全标准	未涵盖	ISO 26262、ISO 25119、ISO 21448 等
典型应用	QM 汽车与农业、工业、测绘、机器人	ADAS、自动驾驶、安全关键型系统

u-blox GNSS 产品的安全性

安全性是一种系统属性，通过严谨的安全工程来实现，即识别危险及其诱因，并预测由此产生的严重程度和发生概率。 一款安全的 GNSS 产品旨在为目标安全应用场景提供具有适当完整性和诊断能力的定位输出。在实践中，这意味着：明确界定的使用假设、对异常状况的稳健检测，以及在要求被违反时采取受控行为（例如：报警、输出限制、备用方案或安全状态）。

UBX-A9940-KA芯片和ZED-A20K模块是u-blox的产品，其设计、开发和验证均遵循既定的安全工程实践，并符合相关质量、安全及保密标准。

• 该 UBX‑A9940‑KA 是 u‑bloxA9 功能安全 GNSS 芯片，配备符合 ISO 26262 ASIL‑B 标准的多星座、多频段测量引擎，用于 GNSS 定位。
• ZED‑A20K 专为混合关键性应用设计，在单个模块中提供符合ASIL-B标准的测量功能和高性能定位解决方案。该模块主要面向自动化级别L2+及以上的高级汽车应用，这些应用对性能、可用性和功能安全有严格要求。

“安全工程”是什么意思？

安全工程是一门致力于确保系统、产品和流程在其整个生命周期内达到可接受安全水平的学科。它识别危害、评估风险，并制定措施以预防或减轻意外伤害。安全工程专注于

• 防范不合理的风险
• 预判可能出现的问题
• 确保即使发生故障也能保持安全行为

并致力于回答三个关键问题：

• 什么可能造成伤害？（危害）
• 这可能如何发生？（失效模式、功能不足、误用）
• 如何确保不会导致伤害？（安全机制 + 证据）

安全工程涉及一系列方法，用于系统地识别危险源、推导安全要求、实施安全机制，并（通过证据）证明残余风险在预期用途下处于可接受范围内。一些成熟的安全分析方法例如：

方法	目的/关键问题	典型输出
HARA （危害分析与风险评估）	在定义的运行场景中存在哪些危害，需要采取哪些风险降低措施？	危害、风险分类（例如 ISO 26262 中的 S/E/C 和 ASIL）、安全目标、高层级安全要求。
FME(D)A （失效模式与影响分析）	项目/功能可能发生哪些失效？会产生什么影响？我们如何检测/缓解这些影响？	失效模式与影响、检测/缓解措施、安全机制/诊断、验证重点。
FTA （故障树分析）	顶层危险事件可能如何发生（包括故障组合）？	故障树、贡献性故障组合、完整性/架构检查，以及对安全论证的支持。

 

安全工程产品可通过故障检测、概率性故障排除、完整性界定以及及时的故障信号指示来应对危险情况，以确保在使用前减轻或安全指示危险的定位误差。处理故障的技术通常组织为一个能力链，涵盖以下步骤

1. 故障检测：检测GNSS 测量或状态中的异常行为，这些行为可能表明存在故障。
2. 故障识别和隔离：一旦检测到异常，确定哪些元素可能出现故障。
3. 故障排除/缓解：防止检测到的故障元素影响位置解。
4. 完整性监测和限定：量化剩余解的可靠性，即使在缓解之后也是如此。
5. 用户/系统故障信号化：确保在无法保证完整性时，系统能够安全地做出反应。

每个步骤都基于前一个步骤，并可能在不同的层次上运行，如信号、卫星、星座、传感器或位置级别。

整体安全领域

有几个主要领域与安全最为相关：

• 功能安全（FuSa）侧重于由故障引起的危害（例如，随机硬件故障、系统性故障）。
• SOTIF（预期功能安全性）侧重于无需故障即可发生的危害，例如因性能限制、感知不足或可预见的误用而导致的危害。
• 网络安全威胁（如干扰/欺骗）可能引发不安全状况，应在整体安全论证和概念中予以考虑。

安全旨在防范系统故障导致的意外伤害，而保障则旨在防范恶意行为导致的蓄意伤害——二者均是实现值得信赖的自主及基于GNSS系统的必要条件，即：

• 安全漏洞可能直接引发安全隐患
• 不安全行为可能被蓄意触发

这种相互依存关系在安全-保障协同工程方法中得到了明确强调，该方法考虑了两个层面的可信度：

• 安全性确保系统在出现故障时仍能安全运行
• 安全性则确保系统不会被蓄意破坏

• 质量工程可视为安全工程的先决条件。它确保系统开发中的系统性缺陷（如需求缺口、设计错误、实现缺陷或验证缺口）不会演变为安全问题。 因此，安全活动需要与整体开发生命周期及控制措施（例如符合ASPICE标准的V模型）紧密衔接，确保从危险源到需求、设计、实现、验证和确认的全过程可追溯性。

所有这些领域均受国际标准和行业定制标准的规范。

与安全相关的汽车和农业标准

安全由各种法规、框架和标准进行规范，这些规范通常针对特定行业量身定制。以下是对与安全GNSS产品开发相关的关键法规和标准范围及目的的简要总结：

🟩 - u-blox 产品的合规性
🟧 - u-blox 产品支持 OEM/设备级合规性

标准/法规	范围（摘要）	与 u-blox GNSS 产品的关系	状态
通用、跨行业的法规、框架和标准
欧盟《机械法规》2023/1230	欧盟法律框架，规定了机械及相关产品的基本健康与安全要求以及符合性评估/CE标志义务，并针对数字技术进行了更新，同时对“实质性修改”和“部分完成机械”等概念进行了澄清。	GNSS通常作为组件存在；OEM需通过风险评估及验证/确认，在机器层面证明其符合性。	🟧
IEC 61508	通用功能安全标准，定义了硬件/软件基于风险的安全生命周期，旨在通过安全完整性等级（SIL 1–4）实现风险降低；是许多行业标准的基础。	该标准适用于安全功能/系统，并不自动适用于独立的GNSS模块；GNSS可作为安全相关输入，通过安全手册证据支持SIL声明，而系统集成商则需在系统层面证明SIL。	🟧
质量管理 / 质量工程
ISO 9001	质量管理体系要求，旨在持续满足客户及法定/监管要求（过程方法、基于风险的思维、绩效评估、持续改进）。	u-blox 的所有定位产品均符合 ISO 9001 标准。	🟩
IATF 16949	与 ISO 9001 结合使用的汽车行业质量管理体系标准，增加了针对供应链的期望，重点在于预防缺陷、减少变异和浪费，并满足客户的特定要求。	u-blox 的所有定位产品均符合 IATF 16949 标准。	🟩
汽车 SPICE® (ASPICE)	用于评估和提升基于软件的电子/电气系统（E/E）在系统与软件工程、管理及支持流程方面能力的汽车行业流程框架。	A9和A20符合ASPICE流程框架。	🟩
针对汽车行业量身定制的标准
ISO 26262	IEC 61508的汽车行业适配版，规定了汽车安全生命周期及工作产品，旨在应对因电子/电气系统故障导致的危害；采用ASIL A–D等级。	A9 和 A20 符合 ISO 26262 ASIL-B(D) 要求。	🟩
ISO 21448	旨在减少因功能不足和可预见的误用（无故障情况下的不安全行为）所导致危害的论证框架和指南，是对 ISO 26262 的补充。	u-blox 定位产品集成了 SOTIF 支持功能，并支持符合 ISO 21448 标准。	🟧
ISO/SAE 21434	针对车辆电子/电气（E/E）全生命周期（包括 TARA）的网络安全风险管理工程要求及相关工作成果；与功能安全标准互为补充。	A9 符合 ISO 21434 标准。	🟩
针对农业行业量身定制的标准
ISO 13849	机械功能安全标准，用于基于类别和性能等级（PL a–e）设计/验证安全相关部件（SRP）和安全控制（CS），以规定安全功能的可靠性。	适用于机器安全功能，并不自动适用于GNSS模块；当GNSS用作与安全相关的输入时，可支持OEM的PL目标。	🟧
ISO 25119	农业/林业拖拉机及机械的行业功能安全标准，适用于通过电子/电气/电力（E/E/PE）系统实现的安全相关控制功能；采用农业性能等级（AgPL）。	A9 和 A20 符合 ISO 26262 标准（最高至 ASIL‑B 级别），因此已具备符合 ISO 25119 标准（最高至 AgPL d 级别）的条件。	🟩
ISO 18497	针对自动化/自主农业机械在预期使用及可预见误用情况下的安全设计原则与指南（包括使用信息/残余风险）。	针对自动化机械功能层面；A9/A20 通过 GNSS 定位（基于定义的假设/限制）、完整性/状态信号以及用于监控和安全回退的集成指南，支持符合 ISO 18497 标准。	🟧

GNSS系统中的安全相关角色与贡献

GNSS的安全作用不能孤立定义，而是源于应用层功能、安全目标和运行理念。 GNSS的安全相关性并非源于技术本身，而是衍生而来的。GNSS是一种实现目的的手段，其所需的安全贡献完全取决于其输出在车辆系统中的使用方式和位置。因此，GNSS的要求和完整性预期是自上而下从应用层面的风险推导出来的，而不是自下而上根据GNSS的能力来规定的。

安全定位并非源于单一组件，而是源于感知、监测、冗余和决策逻辑之间的协调交互。典型的GNSS定位系统由以下部分组成：

• GNSS天线
• 测量引擎
• GNSS校正服务
• 惯性测量单元（IMU）
• 车速传感器（WSS）
• 定位引擎

如图X所示，每个元件都发挥着各自的作用，并在功能安全、SOTIF或这两个领域中均对安全作出贡献。

u-blox 安全产品开发生命周期

以安全为导向的开发方法在“标准”工程基础上增加了具体的规划、分析和证据生成环节。其目标是确保安全要求源于风险，通过适当的机制加以实施，并借助可追溯的工作成果和记录在案的证据进行验证和确认。

典型的安全导向生命周期通常包括：

• 安全管理：安全管理通过定义角色、职责、能力及治理机制来建立组织框架，以确保安全活动能够得到一致的规划、执行和控制。
• 安全规划：安全规划界定实现并证明符合适用安全标准所需的范围、里程碑、工作成果及确认措施。
• 危害分析与风险评估（HARA）：HARA 系统地识别危险场景，并分配完整性目标/所需风险降低量（例如，在适用情况下采用 ASIL/AgPL），以定义安全目标。
• 安全要求：安全要求以明确且可测试的形式记录，并与危害、架构和验证结果保持双向可追溯性。
• 安全概念：安全概念阐述了如何通过架构措施和机制（检测、缓解、安全状态、故障处理）实现安全目标，包括使用假设和系统集成预期。
• 验证与确认：验证表明实现符合规定的安全要求，而确认则表明最终行为对于预期用例和运行场景而言具有可接受的安全性。
• 系统与安全验证：系统级验证确认各接口（包括外部组件和服务）之间的交互正确，并证明安全性能在集成配置中得以保持。
• 审批与产品发布：审批与产品发布确认安全论证完整且有充分证据支持，从而能够做出合理决策，将产品发布用于其预期的与安全相关的用途。

对于 u-blox 开发的 A9 和 ZED-A20K 功能安全型 GNSS 产品，这些活动已通过既定的内部安全和质量流程整合到整体产品开发生命周期中。相应的安全交付成果和支持证据在整个开发过程中持续生成。