1. 文档目的与范围 (Purpose & Scope)
1.1 目的 (Purpose)
本文档旨在定义智能座舱平台中定位子系统的功能、性能、接口及质量需求。本子系统负责为座舱应用（如导航、位置服务、场景感知）提供统一、可靠、高可用的位置、速度、时间、航向等信息，并确保其与整车时间同步系统深度融合，满足功能、性能及安全要求。
1.2 范围 (Scope)
本文档适用于【公司/平台】的智能座舱平台，涵盖定位子系统的多源融合定位（GNSS、IMU、蜂窝网络等）、数据服务、高精度定位使能、与时间同步系统交互等方面。
2. 系统概述 (System Overview)
2.1 系统功能描述 (System Function Description)
座舱定位子系统是智能座舱感知层的关键组成部分，主要功能包括：
-
多源融合定位：融合GNSS（GPS、BDS等）、惯性测量单元（IMU）、蜂窝网络定位、Wi-Fi定位、车载传感器（如轮速）等数据，提供连续、稳定、高精度的位置、速度、时间（PVT）及航向（Heading）解算。
-
高精度定位使能：支持RTK（实时动态定位）、PPP（精密单点定位）等增强服务接口，为高级导航和高精地图匹配提供厘米级定位能力。
-
统一位置服务：为上层应用（导航、AR-HUD、智能语音、位置分享）提供统一、易用的位置数据查询接口（API）。
-
场景自适应：根据环境（如隧道、城市峡谷、地下停车场）动态调整定位策略和源权重，实现无缝定位覆盖。
-
时间同步深度集成：作为GNSS时间的高优先级源接入整车时间同步系统，并为所有定位数据打上统一、可信的时间戳。
2.2 与时间同步系统的关系
定位子系统与时间同步系统存在深度双向依赖：
-
作为高优先级时间源 ：GNSS模块输出的UTC时间是整车最高优先级的外部时间源之一，通过
CarTimeSync服务接入并参与仲裁。 -
依赖统一时基：所有定位数据的生成、融合、上报必须使用整车统一的单调时间和日历时间进行标记，确保跨域数据（如与智驾感知数据）的时间对齐。
-
支持时区解析：提供精确的地理位置信息，作为T-Box或IDC自动判断和切换时区的关键输入。
2.3 系统框图 (System Block Diagram)
+----------------+ +----------------+ +-----------------+
| GNSS接收机 | | IMU (6/9轴) | | 网络定位模块 |
| (多频，多模) | | (加速度/陀螺仪)| | (蜂窝/Wi-Fi) |
+-------+--------+ +-------+--------+ +--------+--------+
| | |
+-------------------+--------------------+
|
+-------v--------+
| 原始数据预处理 |
| (滤波，标定) |
+-------+--------+
|
+-------v--------+ +-------------------+
| 融合定位引擎 <------+ 车辆传感器 |
| (Kalman Filter)| | (CAN: 轮速，转向) |
+-------+--------+ +-------------------+
|
+------------------+------------------+
| | |
+--------v-------+ +--------v-------+ +--------v-------+
| 标准定位服务 | | 高精度定位服务 | | 定位状态管理 |
| (PVT输出) | | (RTK/PPP接口) | | (健康诊断) |
+--------+-------+ +--------+-------+ +--------+-------+
| | |
+------------------+------------------+
|
+-------v--------+
| 统一服务网关 |
| (API, VHAL) |
+-------+--------+
|
+------------------+------------------+
| | |
+--------v-------+ +--------v-------+ +--------v----------------+
| 座舱应用 | | 时间同步系统 | | 其他域控制器 |
| (Nav， AR-HUD) | | (CarTimeSync) | | (智驾， 车身) |
+----------------+ +----------------+ +-------------------------+3. 功能需求 (Functional Requirements)
3.1 需求矩阵 (Requirements Matrix)
| 需求ID | L1功能 | L2功能 | 功能描述 | 海外平台EEA2.5 | 海外平台EEA3.0 | 国内平台 |
|---|---|---|---|---|---|---|
| LOC-FUNC-0101 | 多源数据采集 | GNSS原始数据 | 支持多星座（GPS, GLONASS, BDS, Galileo）多频点原始观测数据（伪距、载波相位）采集与输出。 | ● | ● | ● |
| LOC-FUNC-0102 | 多源数据采集 | IMU原始数据 | 持续采集6轴（加速度、角速度）或9轴（含磁力计）IMU原始数据，输出频率≥100Hz。 | ● | ● | ● |
| LOC-FUNC-0103 | 多源数据采集 | 网络辅助定位 | 支持通过蜂窝网络（A-GNSS）或Wi-Fi（基于MAC地址数据库）获取辅助定位信息。 | ● | ● | ● |
| LOC-FUNC-0201 | 融合定位解算 | 紧组合融合 | 采用紧组合（Tightly Coupled）算法，深度融合GNSS观测量与IMU数据，提升抗遮挡和动态性能。 | ● | ● | ● |
| LOC-FUNC-0202 | 融合定位解算 | 航向解算 | 在GNSS信号不佳时，利用IMU及车辆转向信息，持续输出稳定可靠的航向角。 | ● | ● | ● |
| LOC-FUNC-0203 | 融合定位解算 | 场景自适应 | 根据卫星数、信号强度、车辆运动状态等，自动切换融合策略（如GNSS主导、IMU主导、纯惯性导航）。 | ● | ● | ● |
| LOC-FUNC-0301 | 高精度定位 | RTK使能 | 提供接口接收RTK差分数据（通过蜂窝网络或V2X），输出厘米级定位结果。 | ○ | ● | ● |
| LOC-FUNC-0302 | 高精度定位 | PPP使能 | 提供接口接入PPP校正服务，在无基站区域提供亚米级定位能力。 | ○ | ○ | ● |
| LOC-FUNC-0401 | 时间同步集成 | GNSS时间上报 | 将解析出的GNSS UTC时间、闰秒信息及时间质量标志，实时上报至CarTimeSync服务。 |
● | ● | ● |
| LOC-FUNC-0402 | 时间同步集成 | 定位数据时间戳 | 所有输出的定位数据（位置、速度、航向）必须使用从CarTimeSync获取的整车统一单调时间戳进行标记。 |
● | ● | ● |
| LOC-FUNC-0501 | 服务与接口 | 统一位置API | 为Android/QNX应用提供统一的Java/C++ API，用于查询实时位置、速度、航向及定位状态。 | ● | ● | ● |
| LOC-FUNC-0502 | 服务与接口 | VHAL属性 | 将关键定位状态（如定位模式、精度、卫星数）暴露为车辆硬件抽象层（VHAL）属性，供系统服务诊断。 | ● | ● | ● |
| LOC-FUNC-0503 | 服务与接口 | 车规协议输出 | 通过CAN或SOME/IP协议，将必要的定位信息（如经纬度、高度）发送给智驾、车身等域控制器。 | ● | ● | ● |
| LOC-FUNC-0601 | 性能与可靠性 | 启动首次定位时间 | 冷启动条件下，首次定位时间（TTFF）≤ 30秒；热启动 ≤ 2秒。 | ● | ● | ● |
| LOC-FUNC-0602 | 性能与可靠性 | 定位精度 | 开阔天空条件下，单点定位水平精度 ≤ 2.0米（95%），融合定位水平精度 ≤ 1.0米（95%）。 | ● | ● | ● |
| LOC-FUNC-0603 | 性能与可靠性 | 连续性 | 在短隧道（≤30秒）场景下，依靠IMU保持定位连续，水平位置漂移 ≤ 10米。 | ● | ● | ● |
●：必须支持 ○：可选支持
3.2 GNSS原始数据
| 项目 | 描述 |
| 概述/Overview | 将GNSS接收机解算出的高精度、可追溯至UTC的时间信息，作为最高优先级的外部时间源之一，可靠地上报至整车时间同步管理系统（CarTimeSync）。 |
| 输入/Input | 1. GNSS接收机输出的UTC时间、日期、闰秒信息。 2. GNSS时间状态标志（是否有效、锁定状态、时间不确定性）。 |
| 处理过程/Process | 1. 数据解析与校验 ：解析GNSS协议（如NMEA-0183），获取UTC时间。校验其有效性（如卫星数>4，精度因子良好）。 2. 格式转换与封装 ：将时间信息转换为CarTimeSync服务定义的格式（如Unix时间戳、纳秒级精度）。 3. 服务质量标注 ：附带时间源质量信息（如"GNSS_3D_FIX"）。 4. 周期性上报 ：通过IPC（如Binder）或共享内存调用CarTimeSync的reportGpsTime()接口，以不低于1Hz的频率上报。 |
| 输出/Output | 1. 标准化的GNSS时间戳及质量标签，上报至CarTimeSync。 2. 内部日志，记录每次上报事件及时间值。 |
| 性能要求/Performance | 1. 上报延迟 ：从GNSS模块输出到调用CarTimeSync接口 ≤ 50 ms。 2. 时间精度 ：上报时间戳的精度与GNSS源保持一致（典型值微秒级）。 3. 可用性：GNSS有效时，上报成功率 ≥ 99.9%。 |
| 对运行环境的依赖和影响 | 依赖 ： 1. GNSS硬件模块功能及信号正常。 2. CarTimeSync服务运行且IPC通道畅通。 影响**： 1. 为整车提供最权威的外部时间基准，直接影响所有基于绝对时间的系统功能。** |
| 验证标准/Verification criteria | 1. 在开阔天空下，对比CarTimeSync记录到的GNSS时间与高精度参考时钟，误差在GNSS模块标称精度内。 2. 模拟GNSS信号丢失与恢复，验证上报的启停与状态切换符合预期。 |
| 验证方法/ Verification | 1. 日志分析 ：同时抓取GNSS模块串口日志和CarTimeSync服务日志，对比时间戳的传递延迟和一致性。 2. 仪器测试：使用GNSS信号模拟器注入带有精确时间标记的信号，验证系统上报值。 |
| 可行性/Feasibility | 可行。技术路径清晰，为标准的数据采集与上报流程，依赖的软硬件接口均为平台已有能力。 |
| 可验证性/Verifiability | 高度可验证。可通过日志、系统调试接口和外部测试设备进行定量和定性验证。 |
| 需求分配/Distribution | 系统设计 ：SYE（定义接口协议、服务质量标准） 软件 ：Android（定位服务层实现上报逻辑） 硬件/驱动 ：T1（确保GNSS模块稳定输出） 测试：测试团队（验证功能与性能 |
|---|
3.3 LOC-FUNC-0102 IMU原始数据
| 项目 | 描述 |
| 概述/Overview | 系统应能够持续采集高频率的惯性测量单元原始数据，为融合定位提供车辆运动状态信息，弥补GNSS信号在遮挡环境下的不足。 |
| 输入/Input | 1. IMU传感器输出的加速度计和陀螺仪原始数据。 2. 系统配置：采样频率、量程范围、滤波器设置。 |
| 处理过程/Process | 1. 数据采集 ：通过SPI/I2C接口以≥100Hz频率读取IMU传感器数据。 2. 数据预处理 ：进行温度补偿、零偏校准、标度因数校正。 3. 数据滤波 ：应用低通滤波器减少高频噪声。 4. 时间戳对齐 ：为每个数据样本打上精确的时间戳（与GNSS时间同步）。 5. 数据输出 ：将处理后的数据发送给融合定位引擎。 |
| 输出/Output | 1. 校准后的三轴加速度、三轴角速度数据。 2. 时间戳信息。 3. 数据质量标志（传感器状态、数据有效性）。 |
| 性能要求/Performance | 1. 采样频率 ：数据输出频率 ≥ 100 Hz。 2. 数据延迟 ：从传感器采集到数据输出延迟 ≤ 10 ms。 3. 零偏稳定性 ：加速度计零偏稳定性 ≤ 0.1 mg，陀螺仪零偏稳定性 ≤ 1°/h（典型值）。 4. 数据同步精度 ：IMU数据与GNSS数据时间戳对齐误差 ≤ 1 ms。 |
| 对运行环境的依赖和影响 | 依赖： 1. IMU传感器硬件性能及安装位置（靠近车辆重心为佳）。 2. 传感器标定参数准确。 影响****：**** 1. IMU数据质量直接影响GNSS信号丢失期间的定位连续性。 |
| 验证标准/Verification criteria | 1. 在静态条件下，测量IMU输出数据的噪声水平和零偏稳定性。 2. 在已知运动轨迹下，验证IMU数据积分结果与真实位移的一致性。 3. 验证IMU与GNSS数据的时间同步精度。 |
| 验证方法/ Verification | 1. 实验室测试：使用转台和振动台验证IMU性能指标。 2. 实车测试：在车辆进行标准机动动作时，记录IMU数据并分析其准确性。 |
| 可行性/Feasibility | 可行。车规级MEMS IMU技术成熟，可满足性能要求。 |
| 可验证性/Verifiability | 高度可验证。可通过专业设备对标定后的IMU进行性能测试。 |
| 需求分配/Distribution | 系统设计 ：SYE（定义性能指标、校准流程） 硬件 ：T1（IMU传感器选型、安装设计） 软件 ：Android/QNX（传感器驱动、校准算法） 测试 ：测试团队（性能测试、标定验证） |
|---|
3.4 LOC-FUNC-0103 网络辅助定位
| 项目 | 描述 |
| 概述/Overview | 系统应能通过蜂窝网络或Wi-Fi获取辅助定位信息，加速GNSS首次定位时间，并在GNSS信号弱时提供粗略位置参考。 |
| 输入/Input | 1. 蜂窝网络信号（4G/5G）或Wi-Fi扫描结果（MAC地址列表、信号强度）。 2. 从T-Box或网络模块接收的辅助数据（星历、历书、近似位置等）。 |
| 处理过程/Process | 1. 网络信息获取 ：通过蜂窝网络模块获取基站ID、信号强度等信息；通过Wi-Fi模块扫描周边AP信息。 2. 辅助数据请求 ：向辅助定位服务器（如SUPL服务器）请求星历、历书等数据。 3. 位置解算 ：基于蜂窝三角定位或Wi-Fi指纹数据库计算粗略位置。 4. 数据融合 ：将网络定位结果作为先验信息提供给GNSS接收机，或作为低权重源输入融合引擎。 |
| 输出/Output | 1. 网络辅助数据（星历、历书、近似位置等）。 2. 基于网络的位置估计结果（经纬度、精度半径）。 3. 网络定位状态标志。 |
| 性能要求/Performance | 1. TTFF加速 ：使用A-GNSS时，冷启动TTFF ≤ 15秒。 2. 网络定位精度 ：蜂窝定位精度 ≤ 500米（95%），Wi-Fi定位精度 ≤ 50米（95%）。 3. 数据更新率 ：网络辅助数据更新周期可配置，默认1小时。 |
| 对运行环境的依赖和影响 | 依赖： 1. 蜂窝网络或Wi-Fi连接可用。 2. 辅助定位服务器可访问且数据有效。 影响****：**** 1. 显著改善GNSS启动性能，提升用户体验。 |
| 验证标准/Verification criteria | 1. 在信号屏蔽环境下，验证开启A-GNSS后的TTFF改善效果。 2. 验证网络定位结果在合理精度范围内。 3. 验证网络中断时系统能否优雅降级。 |
| 验证方法/ Verification | 1. 功能测试：模拟不同网络条件，验证A-GNSS和网络定位功能。 ****2. 性能测试：使用网络模拟器控制网络参数，测量定位精度和TTFF。。 |
| 可行性/Feasibility | 可行。A-GNSS和网络定位是成熟技术，主流定位芯片均支持。 |
| 可验证性/Verifiability | 高度可验证。可通过控制网络环境和模拟服务器响应进行测试。 |
| 需求分配/Distribution | 系统设计 ：SYE（定义网络定位策略、数据接口） 软件 ：Android（网络定位服务、SUPL客户端） 网络模块 ：T-Box供应商（提供基站/Wi-Fi数据） 测试 ：测试团队（网络场景测试） |
|---|
3.5 LOC-FUNC-0201 紧组合融合
| 项目 | 描述 |
| 概述/Overview | 系统应采用紧组合算法，深度融合GNSS原始观测量与IMU数据，实现优于松组合的精度和鲁棒性，特别是在信号遮挡和动态场景下。 |
| 输入/Input | 1. GNSS原始观测量（伪距、载波相位）。 2. IMU原始数据（加速度、角速度）。 3. 车辆传感器数据（轮速、转向角）。 4. 时间同步系统提供的统一时间戳。 |
| 处理过程/Process | 1. 时间对齐 ：将多源数据统一到同一时间基准。 2. 状态预测 ：基于IMU数据，使用惯性导航方程预测车辆下一时刻状态（位置、速度、姿态）。 3. 测量更新 ：使用GNSS观测量（伪距、载波相位）对预测状态进行修正，计算卡尔曼滤波增益并更新状态估计。 4. 误差估计与反馈 ：估计并补偿IMU的零偏和标度因数误差，反馈给IMU数据预处理模块。 5. 完整性监测 ：实时监测GNSS观测量质量，排除异常卫星数据。 |
| 输出/Output | 1. 融合后的PVT解（位置、速度、时间）。 2. 车辆姿态角（横滚、俯仰、航向）。 3. 定位结果的不确定性估计（协方差矩阵）。 4. 融合系统状态（收敛、发散、异常）。 |
| 性能要求/Performance | 1. 定位精度 ：开阔天空下，水平定位精度 ≤ 1.0米（95%）。 2. 连续性 ：在GNSS信号部分遮挡时，水平定位误差增长 ≤ 0.1米/秒。 3. 输出频率 ：融合PVT输出频率 ≥ 100 Hz。 4. 计算延迟 ：从数据输入到结果输出延迟 ≤ 20 ms。 |
| 对运行环境的依赖和影响 | 依赖： 1. 高质量的GNSS和IMU原始数据。 2. 准确的传感器标定参数和时间同步。 影响****：**** 1. 提供全场景下最优的定位性能，是定位子系统的核心价值所在。 |
| 验证标准/Verification criteria | 1. 在开阔天空下，对比融合定位结果与高精度参考轨迹，验证精度指标。 2. 在模拟信号遮挡场景（如隧道）下，验证定位连续性和误差增长。 3. 在高动态场景下，验证融合系统跟踪能力。 |
| 验证方法/ Verification | 1. 仿真测试：使用MATLAB/Simulink搭建算法模型，进行大规模场景仿真验证。 2. 实车测试：搭载高精度组合导航系统作为参考，在各种典型场景下进行对比测试。 |
| 可行性/Feasibility | 可行。紧组合算法理论成熟，有开源和商业库可用（如RTKLIB, inertialSense）。但需要较强的算法工程化能力。 |
| 可验证性/Verifiability | 高度可验证。通过与更高精度的参考系统对比，可量化评估性能。 |
| 需求分配/Distribution | 算法设计 ：SYE/算法团队（紧组合滤波器设计、调参） 软件实现 ：Android/QNX（算法移植、优化） 系统集成 ：SYE（数据接口、时间同步） 测试 ：测试团队（性能对标测试） |
|---|
3.6 LOC-FUNC-0202 航向解算
| 项目 | 描述 |
| 概述/Overview | 系统应在GNSS信号不佳或缺失时，利用IMU和车辆传感器数据持续输出稳定可靠的车辆航向角，确保导航系统方向指引的连续性。 |
| 输入/Input | 1. IMU数据（角速度、加速度）。 2. 车辆CAN数据（转向角、轮速）。 3. 最后一次有效的GNSS航向信息。 |
| 处理过程/Process | 1. 航向初始化 ：使用GNSS速度矢量或磁力计（若可用）初始化航向。 2. 陀螺仪积分 ：在GNSS可用时，使用陀螺仪积分计算航向变化，并用GNSS航向进行卡尔曼滤波校正，估计陀螺仪零偏。 3. 航向保持 ：当GNSS不可用时，使用校正后的陀螺仪积分推算航向。 4. 车辆运动约束 ：结合车辆非完整约束（如前进方向近似为航向）和转向角信息，进一步约束航向解算。 5. 异常处理 ：检测并处理陀螺仪异常、磁干扰等情况。 |
| 输出/Output | 1. 车辆航向角（0-360°，以北为0°）。 2. 航向角精度估计（标准差）。 3. 航向解算模式（GNSS主导、IMU主导、车辆约束）。 |
| 性能要求/Performance | 1. 航向精度 ：GNSS可用时，航向角精度 ≤ 0.5°（1σ）。 2. 航向保持 ：GNSS丢失60秒内，航向角漂移 ≤ 2°（静止或直线运动）。 3. 输出延迟 ：航向角输出延迟 ≤ 50 ms。 4. 模式切换平滑性 ：航向解算模式切换时，输出角度无跳变。 |
| 对运行环境的依赖和影响 | 依赖： 1. IMU陀螺仪零偏稳定性。 2. 车辆CAN数据的准确性和延迟。 影响****：**** 1. 在隧道、地下车库等场景，确保导航箭头方向正确，提升用户体验。 |
| 验证标准/Verification criteria | 1. 在开阔天空下，对比系统航向与高精度参考航向，验证精度。 2. 在长隧道中行驶，验证GNSS丢失前后航向的一致性。 3. 验证车辆转弯时航向变化的响应速度和准确性。 |
| 验证方法/ Verification | 1. 转台测试：将IMU安装在转台上，控制精确旋转，验证航向解算精度。 2. 实车测试：安装高精度光纤陀螺作为参考，在各种场景下进行对比测试。 |
| 可行性/Feasibility | 可行。基于IMU的航向保持是成熟技术，结合车辆约束可进一步提升性能。 |
| 可验证性/Verifiability | 高度可验证。可通过参考系统对比进行量化评估。 |
| 需求分配/Distribution | 算法设计 ：SYE/算法团队（航向融合算法） 软件实现 ：Android（航向解算模块） 系统集成 ：SYE（CAN数据接入） 测试 ：测试团队（场景测试、精度验证） |
|---|
3.7 LOC-FUNC-0203 场景自适应
| 项目 | 描述 |
| 概述/Overview | 系统应能自动识别当前定位环境（如开阔天空、城市峡谷、隧道、地下停车场），并动态调整融合定位策略和各数据源的权重，以优化定位精度和连续性。 |
| 输入/Input | 1. GNSS状态信息（卫星数、信噪比、定位模式）。 2. IMU数据质量指标。 3. 车辆运动状态（速度、转向角）。 4. 历史定位轨迹。 5. 地图匹配信息（如已知隧道、高架桥区域）。 |
| 处理过程/Process | 1. 特征提取 ：实时计算GNSS可用卫星数、DOP值、信噪比分布、IMU数据噪声水平等特征。 2. 场景分类 ：基于规则或机器学习模型，将当前环境分类为：开阔天空、城市峡谷、隧道、地下停车场、高架桥下等。 3. 策略调整 ：根据场景分类结果，动态调整： a) 融合滤波器中GNSS观测量的噪声方差矩阵。 b) IMU零偏估计的更新速率。 c) 是否启用车辆运动约束。 d) 是否切换到纯惯性导航模式。 4. 平滑过渡 ：策略切换时，采用平滑过渡机制，避免定位结果跳变。 |
| 输出/Output | 1. 当前场景分类结果。 2. 融合定位策略参数。 3. 定位性能自评估报告。 |
| 性能要求/Performance | 1. 场景识别准确率 ：对开阔天空、隧道等典型场景的识别准确率 ≥ 95%。 2. 识别延迟 ：场景变化到系统识别并完成策略调整 ≤ 3秒。 3. 策略有效性 ：启用场景自适应后，在挑战性环境下的定位精度提升 ≥ 30%（相对于固定策略）。 |
| 对运行环境的依赖和影响 | 依赖： 1. 准确的场景特征提取和分类模型。 2. 足够丰富的训练数据。 影响****：**** 1. 显著提升复杂环境下的定位鲁棒性，是智能定位系统的关键特征。 |
| 验证标准/Verification criteria | 1. 在包含多种场景的固定路线上测试，验证场景识别准确率。 2. 对比开启/关闭场景自适应功能在相同挑战性路段（如长隧道出口）的定位表现。 3. 验证策略切换过程中定位输出的平滑性。 |
| 验证方法/ Verification | 1. 数据回放测试：采集大量实车数据，离线回放验证场景识别算法。 2. 实车路测：设计覆盖典型场景的测试路线，进行系统性测试。 3. 仿真测试：使用仿真工具生成各种场景的传感器数据，进行算法验证。 |
| 可行性/Feasibility | 可行。基于规则和机器学习的场景识别是当前研究热点，已有较多工程实践。 |
| 可验证性/Verifiability | 可验证。可通过设计针对性场景进行测试验证。 |
| 需求分配/Distribution | 算法设计 ：SYE/算法团队（场景识别算法、自适应策略） 软件实现 ：Android（场景识别模块、策略管理） 数据采集 ：测试团队（采集训练和测试数据） 测试 ：测试团队（场景覆盖测试） |
|---|
3.8 LOC-FUNC-0301 RTK使能
| 项目 | 描述 |
| 概述/Overview | 系统应提供实时动态定位接口，能够接收并处理RTK差分数据，实现厘米级高精度定位，满足车道级导航、高精地图匹配等应用需求。 |
| 输入/Input | 1. GNSS原始观测数据（基准站和移动站）。 2. RTK差分数据（通过蜂窝网络、V2X或本地电台接收）。 3. 差分数据格式配置（RTCM 2.x/3.x）。 |
| 处理过程/Process | 1. 差分数据接收 ：通过蜂窝网络模块或专用RTK接收机接收差分数据。 2. 数据解析与同步 ：解析RTCM报文，并将差分数据与本地GNSS观测数据在时间上对齐。 3. 整周模糊度解算 ：使用载波相位观测值，采用LAMBDA等方法解算整周模糊度。 4. 固定解计算 ：在模糊度固定后，计算厘米级精度的位置解。 5. 质量控制 ：检查固定解的Ratio值、残差等指标，确保结果可靠。 6. 结果输出 ：输出固定解、浮点解及对应的精度指标。 |
| 输出/Output | 1. RTK定位结果（固定解/浮点解）。 2. 定位精度（水平/高程）。 3. RTK状态（初始化、固定、浮点、无效）。 4. 质量指标（Ratio值、卫星数）。 |
| 性能要求/Performance | 1. 定位精度 ：固定解水平精度 ≤ 2 cm（1σ），高程精度 ≤ 3 cm（1σ）。 2. 初始化时间 ：在良好条件下，RTK初始化时间（TTFF）≤ 30秒。 3. 固定率 ：开阔天空下，RTK固定率 ≥ 95%。 4. 差分数据延迟容忍 ：能处理延迟 ≤ 5秒的差分数据。 |
| 对运行环境的依赖和影响 | 依赖： 1. 稳定的差分数据源（基准站网络或V2X）。 2. 高质量的GNSS原始数据（多频点）。 影响****：**** 1. 实现车道级定位能力，是高级自动驾驶功能的基础。 |
| 验证标准/Verification criteria | 1. 在已知坐标点上进行静态测试，验证RTK固定解的精度和重复性。 2. 在动态场景下，对比RTK轨迹与高精度参考轨迹。 3. 测试在差分数据中断时的降级恢复能力。 |
| 验证方法/ Verification | 1. 基准站测试：搭建本地基准站，在已知基线长度下进行精度测试。 2. 网络RTK测试：接入商业网络RTK服务，进行大范围动态测试。 3. 对比测试：使用专业高精度接收机作为参考。 |
| 可行性/Feasibility | 可行。RTK技术成熟，有多种商业和开源解决方案（如RTKLIB）。但需要解决车规环境下的可靠性和成本问题。 |
| 可验证性/Verifiability | 高度可验证。可通过已知坐标点或参考系统进行精度验证。 |
| 需求分配/Distribution | 系统设计 ：SYE（定义RTK集成方案） 硬件 ：T1（支持多频RTK的GNSS接收机） 算法 ：算法团队（RTK算法移植与优化） 软件 ：Android（RTK服务、数据接口） 测试 ：测试团队（精度测试、场景测试） |
|---|
3.9 LOC-FUNC-0302 PPP使能
| 项目 | 描述 |
| 概述/Overview | 系统应提供精密单点定位接口，能够利用精密星历和钟差产品，在全球范围内无需本地基准站的情况下实现亚米级定位精度 |
| 输入/Input | 1. GNSS原始观测数据（多频点）。 2. 精密星历和钟差产品（通过互联网或卫星播发接收）。 3. 相位缠绕、潮汐、天线相位中心等误差模型参数。 |
| 处理过程/Process | 1. 精密产品获取 ：从服务器下载或实时接收精密星历（如IGS最终/快速产品）和钟差。 2. 误差修正 ：应用各种精密误差模型修正观测值，包括：卫星天线相位中心、相位缠绕、固体潮、海洋负荷、对流层延迟（使用模型或估计）、电离层延迟（使用双频消除或全球电离层地图）。 3. 参数估计 ：使用扩展卡尔曼滤波等方法，估计位置、接收机钟差、对流层延迟、浮点模糊度等参数。 4. 收敛判断 ：监测位置估计的收敛状态，通常在20-30分钟后达到亚米级精度。 5. 结果输出 ：输出PPP定位结果及精度指标。 |
| 输出/Output | 1. PPP定位结果（经纬度、高度）。 2. 定位精度估计。 3. PPP状态（收敛中、已收敛、发散）。 4. 收敛时间。 |
| 性能要求/Performance | 1. 定位精度 ：收敛后，静态水平精度 ≤ 0.2米（95%），高程精度 ≤ 0.3米（95%）。 2. 收敛时间 ：在良好条件下，收敛到亚米级精度所需时间 ≤ 30分钟。 3. 动态性能 ：动态条件下，水平精度 ≤ 0.5米（95%）。 4. 产品延迟容忍 ：支持使用数小时前的精密产品。 |
| 对运行环境的依赖和影响 | 依赖： 1. 可获取的精密星历和钟差产品。 2. 多频GNSS观测数据以消除电离层延迟。 影响****：**** 1. 为无基准站区域（如海洋、偏远地区）提供高精度定位可能。 |
| 验证标准/Verification criteria | 1. 在已知坐标点上进行长时间静态测试，验证PPP收敛后的精度。 2. 对比PPP动态轨迹与参考轨迹。 3. 测试不同精密产品（最终、快速、超快速）下的性能差异。 |
| 验证方法/ Verification | 1. 静态测试：在已知点进行24小时以上数据采集，进行后处理PPP解算，分析精度和收敛时间。 2. 动态测试：使用高精度参考系统对比。 3. 产品测试：测试不同来源和延迟的精密产品对定位性能的影响。 |
| 可行性/Feasibility | 可行。PPP算法成熟，有开源实现（如RTKLIB的PPP模块）。主要挑战在于收敛时间和车载环境下的可靠性。 |
| 可验证性/Verifiability | 高度可验证。可通过长时间静态测试验证其理论精度。 |
| 需求分配/Distribution | 算法设计 ：算法团队（PPP算法研究与优化） 系统设计 ：SYE（定义产品获取与更新机制） 软件 ：Android（PPP服务、数据管理） 测试 ：测试团队（长时测试、性能评估） |
|---|
3.10LOC-FUNC-0402 定位数据时间戳
| 项目 | 描述 |
| 概述/Overview | 所有输出的定位数据（位置、速度、航向）必须使用从整车时间同步系统获取的统一单调时间戳进行标记，确保跨域数据的时间一致性和可追溯性。 |
| 输入/Input | 1. 定位子系统内部生成的定位结果（PVT、航向等）。 2. 从CarTimeSync服务获取的当前高精度单调时间戳（如CLOCK_MONOTONIC）。 |
| 处理过程/Process | 1. 时间戳请求 ：在准备输出一批定位数据时，立即向CarTimeSync服务请求当前时间戳。建议使用高精度调用（如clock_gettime(CLOCK_MONOTONIC)），该调用已由CarTimeSync同步到统一时基。 2. 时间戳关联 ：将该时间戳与定位数据严格绑定。对于异步处理管道，需确保数据与时间戳的正确对应关系，避免错位。 3. 数据封装 ：将时间戳作为元数据的一部分，与定位数据一同封装到输出数据结构或消息中。 4. 输出 ：将带时间戳的定位数据发送给内部模块或通过API/VHAL/CAN输出给消费者。 |
| 输出/Output | 1. 附带精确时间戳的定位数据包。 2. 时间戳同步状态（正常/异常）。 |
| 性能要求/Performance | 1. 时间戳精度 ：时间戳与数据实际生成时刻的偏差 ≤ 1 ms。 2. 时间戳获取延迟 ：从调用时间接口到获得时间戳的延迟 ≤ 100 µs。 3. 一致性 ：所有输出通道（API、VHAL、CAN）的同一组定位数据携带相同的时间戳。 |
| 对运行环境的依赖和影响 | 依赖： 1. CarTimeSync服务正常运行并提供高精度时间。 2. 系统提供低延迟的时间查询接口。 影响****：**** 1. 是实现多传感器（如摄像头、雷达）数据融合时，时间对齐的基础。 |
| 验证标准/Verification criteria | 1. 注入已知时间模式的定位数据，检查输出数据包的时间戳序列是否连续、无跳变、与注入时间对齐。 2. 对比定位数据时间戳与外部高精度时间参考（如PPS信号）的差异。 3. 验证多输出通道时间戳的一致性。 |
| 验证方法/ Verification | 1. 注入测试：开发测试工具，模拟生成带时间标记的定位数据，验证系统输出时间戳的正确性。 2. 硬件测试：使用带时间标记的信号源（如GNSS模拟器输出PPS）和逻辑分析仪，测量实际输出时间戳的精度。 3. 日志分析：在系统关键节点打时间戳日志，进行端到端延迟分析。 |
| 可行性/Feasibility | 可行。本质是软件工程的最佳实践，技术上无难点，但需要在整个数据处理链路上进行严格的设计和测试。 |
| 可验证性/Verifiability | 高度可验证。可通过时间注入和硬件测量进行定量验证。 |
| 需求分配/Distribution | 系统设计 ：SYE（定义时间戳规范、数据流设计） 软件实现 ：Android（在所有数据输出点集成时间戳调用） 测试 ：测试团队（时间戳精度与一致性测试） |
|---|
3.11 LOC-FUNC-0501 统一位置API
| 项目 | 描述 |
| 概述/Overview | 为上层应用程序提供一套统一、易用、高性能的位置数据查询接口（API），隐藏底层定位技术的复杂性，确保应用能可靠地获取所需的位置、速度、航向等信息。 |
| 输入/Input | 1. 应用程序的API调用请求（如获取最后一次已知位置、请求位置更新）。 2. 定位子系统内部产生的带时间戳的定位数据。 3. 系统权限设置（如应用是否具有位置访问权限）。 |
| 处理过程/Process | 1. 权限验证 ：检查调用应用的权限，拒绝无权限访问。 2. 请求解析 ：解析API请求参数（如所需精度、更新频率、功耗模式）。 3. 数据匹配 ：从定位引擎缓存或实时流中匹配符合要求的数据（如精度、新鲜度）。 4. 数据封装 ：将定位数据封装成标准格式（如Android的Location对象）。 5. 回调或返回 ：根据调用方式（同步或异步）将结果返回给应用。 6. 生命周期管理 ：管理应用对位置更新的订阅，在应用退订或结束时停止不必要的定位计算以节省资源。 |
| 输出/Output | 1. 标准格式的位置数据返回给应用程序。 2. 权限错误或参数错误等异常信息。 3. 系统日志，记录API调用情况用于诊断。 |
| 性能要求/Performance | 1. API响应时间 ：同步调用返回时间 ≤ 10 ms（命中缓存）。 2. 数据新鲜度 ：通过API获取的位置数据时间戳与当前时间的延迟 ≤ 定位数据输出周期+100 ms。 3. 并发支持 ：支持至少20个应用同时订阅位置更新。 4. 功耗影响 ：在满足应用需求的前提下，优化后台定位策略，最小化功耗。 |
| 对运行环境的依赖和影响 | 依赖： 1. 底层定位引擎稳定输出数据。 2. 系统权限管理框架正常工作。 影响****：**** 1. 是大多数座舱位置相关应用（导航、天气、本地服务）的基石，直接影响用户体验。 |
| 验证标准/Verification criteria | 1. 开发测试应用，调用所有API接口，验证返回数据的正确性和格式。 2. 验证权限控制机制是否有效。 3. 测试在高频率、多应用并发调用下的稳定性和性能。 4. 测量不同API调用模式下的系统功耗。 |
| 验证方法/ Verification | 1. 单元测试：对API模块进行全面的单元测试。 2. 集成测试：开发多个测试应用模拟真实使用场景。 3. 压力测试：使用自动化工具模拟高并发请求。 4. 功耗测试：在暗室中使用电源分析仪测量API调用对系统功耗的影响。 |
| 可行性/Feasibility | 可行。Android系统本身已提供LocationManager等成熟API框架，基于此进行定制和增强即可。 |
| 可验证性/Verifiability | 高度可验证。可通过开发测试程序进行全面验证。 |
| 需求分配/Distribution | 系统设计 ：SYE（定义API接口规范） 软件实现 ：Android（基于AOSP Location框架进行增强和定制） 测试 ：测试团队（API功能、性能、兼容性测试） |
|---|
3.12 LOC-FUNC-0502 VHAL属性
| 项目 | 描述 |
| 概述/Overview | 将定位子系统的关键状态、配置和诊断信息以车辆硬件抽象层属性的形式暴露，供车辆诊断系统、工程测试工具和其他系统服务查询和监控。 |
| 输入/Input | 1. 定位子系统内部状态（定位模式、卫星数、精度、融合状态等）。 2. 诊断命令请求（通过VHAL接口）。 |
| 处理过程/Process | 1. 属性定义 ：在VHAL属性列表中定义一组定位相关的属性（如VEHICLE_PROPERTY_LOCATION_STATUS, VEHICLE_PROPERTY_GNSS_SATELLITE_INFO）。 2. 状态映射 ：建立从定位引擎内部状态到VHAL属性值的映射关系。 3. 属性更新 ：当内部状态变化时，主动更新VHAL属性值（对于可读属性）。 4. 请求响应 ：响应来自VHAL客户端的属性读取或设置请求。 5. 权限控制 ：对敏感属性（如原始位置数据）的访问进行权限控制。 |
| 输出/Output | 1. 更新的VHAL属性值，可供订阅者获取。 2. 对属性设置请求的响应（成功/失败）。 |
| 性能要求/Performance | 1. 属性更新延迟 ：内部状态变化到VHAL属性更新的延迟 ≤ 200 ms。 2. 查询响应时间 ：响应属性查询请求的延迟 ≤ 50 ms。 3. 属性数量 ：支持至少20个定位相关属性。 |
| 对运行环境的依赖和影响 | 依赖： 1. 车辆硬件抽象层（VHAL）框架正常运行。 2. 定位引擎提供清晰的状态接口。 影响****：**** 1. 为车辆诊断、产线测试、售后维修提供了标准化的状态访问接口。 |
| 验证标准/Verification criteria | 1. 使用标准VHAL测试工具（如 lshal****）或开发测试程序，查询所有定义的定位属性，验证值与实际状态一致。**** 2. 模拟状态变化，验证属性更新是否及时。 3. 验证属性读写权限控制是否生效。 |
| 验证方法/ Verification | 1. 工具测试：使用Android HAL测试工具进行自动化测试。 2. 集成测试：与诊断系统集成测试。 3. 功能测试：人工操作触发各种定位状态，检查VHAL属性变化。 |
| 可行性/Feasibility | 可行。VHAL是Android Automotive的标准框架，扩展属性是常规操作。 |
| 可验证性/Verifiability | 高度可验证。可通过标准化工具和自定义测试程序验证。 |
| 需求分配/Distribution | 系统设计 ：SYE（定义属性列表、数据类型、权限） 软件实现 ：Android（实现VHAL定位属性服务） 测试 ：测试团队（VHAL属性功能与集成测试） |
|---|
3.13 LOC-FUNC-0503 车规协议输出
| 项目 | 描述 |
| 概述/Overview | 将必要的定位信息（如经纬度、高度、速度、航向、精度）通过车载网络（CAN或SOME/IP）以标准化的协议格式发送给其他域控制器（如智驾、车身、底盘），满足跨域功能对位置信息的需求。 |
| 输入/Input | 1. 定位子系统生成的带时间戳的定位数据。 2. 目标网络协议配置（CAN DB或SOME/IP服务描述文件）。 3. 其他域的订阅请求（对于SOA）。 |
| 处理过程/Process | 1. 数据筛选与转换 ：从完整的定位数据中提取目标域所需的信息，并转换为符合协议规定的数据类型和单位（如度转为0.000001度，米/秒转为0.01 km/h）。 2. 协议封装 ： a) CAN ：将数据填充到预定义的CAN信号中，计算校验和，封装成CAN报文。 b) SOME/IP ：将数据序列化为SOME/IP服务方法或事件的数据结构。 3. 定时/事件触发发送 ： a) CAN ：以固定周期（如100ms）发送。 b) SOME/IP ：以事件方式通知订阅者，或响应方法调用。 4. 网络管理 ：处理网络唤醒、休眠等状态下的发送策略。 |
| 输出/Output | 1. 符合车规网络协议的定位数据报文（CAN帧或SOME/IP消息）。 2. 发送状态统计（成功、失败、超时）。 |
| 性能要求/Performance | 1. 发送周期稳定性 ：CAN报文发送周期抖动 ≤ ±10%。 2. 端到端延迟 ：从定位数据生成到报文发出 ≤ 50 ms。 3. 协议符合性 ：报文格式、信号定义、通信矩阵100%符合整车设计规范。 |
| 对运行环境的依赖和影响 | 依赖： 1. 车载网络通信栈（CAN Stack, SOME/IP Stack）正常工作。 2. 整车通信矩阵（DBC, ARXML）定义清晰且稳定。 影响****：**** 1. 是实现智驾融合定位、车身位置服务（如迎宾灯）等功能的关键数据桥梁。 |
| 验证标准/Verification criteria | 1. 使用CANoe/Vehicle Spy等工具捕捉网络报文，验证数据内容、周期、格式与通信矩阵一致。 2. 模拟定位数据变化，验证输出报文内容同步更新。 3. 在网络负载压力下，验证报文发送的实时性和可靠性。 |
| 验证方法/ Verification | 1. 网络抓包分析：使用专业工具进行离线或在线分析。 2. 仿真测试：在台架中模拟完整车载网络环境，进行系统集成测试。 3. 实车测试：在实车中验证与其他域控制器的实际通信效果。 |
| 可行性/Feasibility | 可行。基于成熟的AUTOSAR通信栈或开源SOME/IP实现，工程实现明确。 |
| 可验证性/Verifiability | 高度可验证。网络报文是可观测的，便于分析和测试。 |
| 需求分配/Distribution | 系统设计 ：SYE（定义通信矩阵、报文内容） 网络集成 ：网络团队（DBC/ARXML设计、网络负载评估） 软件实现 ：Android/QNX（CAN/SOME/IP通信模块） 测试 ：测试团队（协议符合性、网络集成测试） |
|---|
3.14 LOC-FUNC-0601 启动首次定位时间
| 项目 | 描述 |
| 概述/Overview | 系统在冷启动（长时间断电后）或热启动条件下，应能快速完成首次定位，满足用户对定位服务即时性的要求。 |
| 输入/Input | 1. 系统上电或唤醒信号。 2. GNSS天线信号。 3. 可能的辅助数据（星历、历书、近似位置、时间）。 |
| 处理过程/Process | 1. 模块初始化 ：GNSS接收机、IMU等硬件上电初始化，软件服务启动。 2. 辅助数据加载 ：尝试从非易失存储加载上次保存的星历、历书、近似位置和時間。如果可用且未过期，进入热启动流程；否则进入冷启动。 3. 卫星搜索 ：根据可用信息，在可能的频点和空间范围内搜索卫星信号。 4. 信号捕获与跟踪 ：捕获卫星信号并建立稳定跟踪。 5. 定位解算 ：获得至少4颗卫星的有效观测后，解算位置。 6. 融合初始化 ：将首次GNSS定位结果与IMU等进行对齐，初始化融合滤波器。 |
| 输出/Output | 1. 首次有效的定位结果（PVT）。 2. TTFF值（可用于诊断和日志）。 3. 启动类型（冷/热/温启动）。 |
| 性能要求/Performance | 1. 冷启动TTFF ：无任何先验信息，开阔天空下 ≤ 30秒。 2. 热启动TTFF ：有有效星历、近似位置和时间，开阔天空下 ≤ 2秒。 3. 温启动TTFF ：有过期星历， ≤ 15秒。 4. A-GNSS辅助TTFF ：有网络辅助数据， ≤ 15秒（冷启动条件下）。 |
| 对运行环境的依赖和影响 | 依赖： 1. GNSS信号质量。 2. 辅助数据的有效性和存储可靠性。 影响****：**** 1. 直接影响用户上车后使用导航等位置服务的等待时间，是重要的用户体验指标。 |
| 验证标准/Verification criteria | 1. 在标准测试环境（开阔天空）下，多次重复冷/热启动，统计TTFF满足性能要求的比例（应≥95%）。 2. 验证辅助数据存储和加载功能正常，能有效缩短TTFF。 |
| 验证方法/ Verification | 1. 标准测试：使用GNSS信号模拟器，模拟冷/热启动条件，精确测量TTFF。 2. 实车测试：在真实环境下，进行多次上电重启测试，记录并分析TTFF数据。 3. 辅助数据测试：模拟删除辅助数据文件，验证冷启动性能；注入有效辅助数据，验证热启动性能。 |
| 可行性/Feasibility | 可行。TTFF是GNSS模块的关键性能指标，主流模块均可满足。通过优化辅助数据管理和使用A-GNSS可进一步改善。 |
| 可验证性/Verifiability | 高度可验证。TTFF是可测量的明确指标。 |
| 需求分配/Distribution | 系统设计 ：SYE（定义TTFF指标、辅助数据管理策略） 硬件 ：T1（选择TTFF性能达标的GNSS模块） 软件 ：Android（辅助数据存储与加载逻辑、TTFF测量点） 测试 ：测试团队（TTFF专项测试） |
|---|
3.15 LOC-FUNC-0602 定位精度
| 项目 | 描述 |
| 概述/Overview | 系统在各种典型环境下应达到规定的定位精度水平，为上层应用提供可靠的位置信息。 |
| 输入/Input | 1. 多源传感器数据（GNSS, IMU等）。 2. 环境信息（可间接从信号质量推断）。 3. 高精度定位增强数据（RTK/PPP，若启用）。 |
| 处理过程/Process | 1. 数据质量评估 ：实时评估各传感器数据质量。 2. 融合解算 ：执行紧组合等融合算法，输出最优估计位置及其协方差（精度估计）。 3. 环境自适应 ：在信号好的环境（开阔天空）主要依赖GNSS；在信号差的环境（城市峡谷）加大IMU权重；在隧道内切换至纯惯性导航。 4. 增强定位 ：如果启用RTK/PPP，则调用相应模块输出高精度解。 |
| 输出/Output | 1. 定位结果（经纬度、高度）。 2. 定位精度估计值（如CEP95，水平/垂直精度）。 3. 当前定位模式（GNSS, GNSS+IMU, DR等）。 |
| 性能要求/Performance | 1. 开阔天空 ：单点定位水平精度 ≤ 2.0米（95%），融合定位水平精度 ≤ 1.0米（95%）。 2. 城市峡谷 ：融合定位水平精度 ≤ 5.0米（95%）。 3. 隧道内（惯性） ：60秒内水平位置误差增长 ≤ 10米（95%）。 4. RTK固定解 ：水平精度 ≤ 2厘米（1σ）。 5. PPP收敛后 ：水平精度 ≤ 0.2米（95%）。 |
| 对运行环境的依赖和影响 | 依赖： 1. 环境因素（卫星几何分布、多径、遮挡）。 2. 传感器性能（GNSS接收机、IMU等级）。 影响****：**** 1. 定位精度直接决定导航、ADAS等功能的可用性和安全性。 |
| 验证标准/Verification criteria | 1. 在受控测试场（有已知坐标参考点）进行静态和动态精度测试。 2. 在典型城市峡谷、高架桥下、林荫道等真实场景进行精度测试。 3. 对比系统输出的精度估计值与实测误差，验证其置信度。 |
| 验证方法/ Verification | 1. 参考系统对比：使用高精度组合导航系统（如NovAtel SPAN）作为参考真值，进行实车对比测试。 2. 固定点测试：在已知精确坐标的点上长时间静态测试，计算误差统计。 3. 场景测试：设计包含多种环境的固定测试路线，重复行驶采集数据进行分析。 |
| 可行性/Feasibility | 可行。通过选用性能达标的硬件和优化融合算法，可以达到上述精度目标。但极限环境（如深峡谷）下的精度保障具有挑战性。 |
| 可验证性/Verifiability | 高度可验证。通过与更高精度的参考系统对比，可以定量评估。 |
| 需求分配/Distribution | 系统设计 ：SYE（定义精度指标、测试场景） 硬件 ：T1（选择满足精度潜力的传感器） 算法 ：算法团队（优化融合算法以达成精度目标） 测试 ：测试团队（精度对标测试、场景测试 |
|---|
3.16 LOC-FUNC-0603 连续性
| 项目 | 描述 |
| 概述/Overview | 系统在GNSS信号暂时中断（如短隧道、高架桥下）时，应能利用惯性导航等技术保持定位输出的连续性，避免位置跳变或丢失，确保导航等应用的流畅体验。 |
| 输入/Input | 1. GNSS信号状态（是否中断、信号质量）。 2. IMU数据（加速度、角速度）。 3. 车辆传感器数据（轮速、转向角）。 4. 信号中断前最后的高精度位置和速度信息。 |
| 处理过程/Process | 1. 中断检测 ：实时监测GNSS卫星数、信噪比等，判断信号是否中断或严重恶化。 2. 模式切换 ：当检测到中断时，平滑地从"GNSS/IMU融合模式"切换到"纯惯性导航（DR）模式"。 3. 惯性推算 ：在DR模式下，基于IMU和车辆里程计数据，积分推算当前位置、速度和航向。 4. 误差抑制 ：应用车辆运动约束（非完整约束），并利用地图匹配（如已知在隧道内）等信息，约束推算误差的增长。 5. 重捕获处理 ：当GNSS信号恢复时，快速将惯性推算的位置与GNSS新位置进行比对和校正，平滑切换回融合模式，并重新校准IMU误差。 |
| 输出/Output | 1. 连续不间断的定位数据流。 2. 定位模式标识（融合/DR）。 3. 信号中断/恢复事件通知。 |
| 性能要求/Performance | 1. 短隧道保持 ：在长度≤500米、直线行驶的隧道中，全程定位输出连续，出口处水平位置误差 ≤ 10米（95%）。 2. 模式切换平滑性 ：模式切换时，位置、速度输出无跳变（变化率连续）。 3. 中断检测延迟 ：从GNSS信号实际丢失到系统识别并切换模式 ≤ 1秒。 4. 重捕获收敛时间 ：信号恢复后，在10秒内定位精度恢复到正常水平。 |
| 对运行环境的依赖和影响 | 依赖： 1. IMU和车辆里程计数据的准确性。 2. 中断检测算法的灵敏度和鲁棒性。 影响****：**** 1. 确保用户在穿越隧道等场景时导航不中断，提升产品体验的可靠性。 |
| 验证标准/Verification criteria | 1. 在模拟隧道或实际短隧道中多次测试，统计出口处定位误差满足要求的比例。 2. 分析数据日志，验证模式切换过程平滑，无跳变。 3. 模拟GNSS信号瞬间中断与恢复，验证检测和收敛时间。 |
| 验证方法/ Verification | 1. 实车隧道测试：选择不同长度和线形的隧道进行测试，使用参考轨迹评估连续性误差。 2. 信号模拟器测试：使用GNSS信号模拟器，精确控制信号中断和恢复的时机，进行可重复的测试。 3. 数据回放分析：采集包含中断场景的实车数据，离线回放分析算法行为。 |
| 可行性/Feasibility | 可行。惯性导航和里程计推算技术成熟，结合车辆约束和地图信息可以有效抑制误差增长。 |
| 可验证性/Verifiability | 高度可验证。可通过特定场景的实车测试和信号模拟进行验证。 |
| 需求分配/Distribution | 算法设计 ：SYE/算法团队（DR算法、中断检测、模式平滑切换） 软件实现 ：Android（模式管理、连续性保障逻辑） 测试 ：测试团队（隧道场景专项测试、信号中断模拟测试） |
|---|
4. 系统原型 (System Prototype)
4.1 物理原型 (Physical Prototype)
注：硬件依赖。
-
GNSS天线：支持多频点，抗干扰，安装位置符合整车EMC要求。
-
GNSS接收机模块：车规级，支持多模多频，具备原始观测值输出。
-
IMU模块：车规级6/9轴MEMS传感器，与主机通过SPI/I2C高速通信。
4.2 用户界面原型 (User Interface Prototype)
注：定位子系统主要为后台服务，UI体现于应用层。
-
设置界面：提供"定位服务开关"、"高精度模式开关"、"定位数据清除"等入口。
-
诊断界面：在工程模式下，显示实时卫星星空图、信号强度、融合状态、各源权重等详细信息。
5. 接口需求 (Interface Requirements)
5.1 外部接口 (External Interfaces)
| 接口名称 | 类型 | 描述 |
|---|---|---|
CarTimeSync |
服务接口 | 上报GNSS时间，查询统一时间戳。 |
Vehicle CAN Bus |
总线接口 | 输入轮速、转向角等车辆信号；输出标准位置报文（如Pose）。 |
Cellular Modem |
网络接口 | 接收A-GNSS辅助数据及RTK/PPP差分数据。 |
Audio Manager |
服务接口 | 在特定场景（如隧道惯性导航）下，可能需要音频提示。 |
5.2 内部接口 (Internal Interfaces)
| 接口模块 | 描述 |
|---|---|
GNSS Driver HAL |
提供GNSS模块控制、数据读取原始接口。 |
IMU Sensor HAL |
提供IMU传感器数据高速采集接口。 |
Fusion Engine Core |
核心算法库，输入多源原始数据，输出融合后的PVT。 |
Location Service API |
对上应用暴露的标准化查询接口。 |
6. 设计约束 (Design Constraints)
| 约束类型 | 描述 |
|---|---|
| 硬件平台 | 必须采用平台指定的车规级GNSS芯片（如U-blox F9系列，高通QCM6490内置）及IMU传感器。 |
| 操作系统 | Android R及以上，需实现HIDL/AIDL接口；QNX侧需实现POSIX兼容接口。 |
| 算法性能 | 融合定位引擎在指定硬件（如RK3588）上的CPU占用率峰值 ≤ 15%。 |
| 数据安全 | 用户地理位置数据必须加密存储，对外传输需脱敏或获得用户明确授权。 |
7. 质量需求 (Quality Requirements)
| 类别 | 需求ID | 描述 | 验证标准 |
|---|---|---|---|
| 性能 | LOC-QUAL-0101 | 精度：城市峡谷环境，融合定位水平精度 ≤ 5米 (95%)。 | 实车在典型城市峡谷路段测试，对比参考轨迹。 |
| 性能 | LOC-QUAL-0102 | 延迟：从传感器数据采集到应用API可查询到新位置的总延迟 ≤ 100ms。 | 使用高精度时间戳注入与采集工具测量。 |
| 可靠性 | LOC-QUAL-0201 | MTBF：定位子系统软件服务平均无故障运行时间 ≥ 5000小时。 | 依据可靠性测试标准进行长时压力测试。 |
| 安全性 | LOC-QUAL-0301 | 功能安全：输出给智驾域的位置、速度数据应满足ASIL-B等级要求（若智驾需求）。 | 按照ISO 26262进行流程和产品审核。 |
| 信息安全 | LOC-QUAL-0401 | 隐私保护：未经用户授权，不得将原始GNSS数据或高精度位置信息上传至云端。 | 进行渗透测试与数据流审计。 |
| 可维护性 | LOC-QUAL-0501 | 诊断：支持通过诊断命令读取定位引擎内部状态、故障码及性能统计信息。 | 使用诊断工具验证命令可达性与数据正确性。 |
8. 实施需求 (Implement Requirements)
8.1 测试验证需求
-
MIL/SIL测试：对融合定位算法模型进行模型在环/软件在环测试。
-
HIL测试：在硬件在环台架中，接入GNSS信号模拟器、IMU仿真器和CANoe，模拟复杂场景。
-
实车路测：覆盖开阔天空、城市峡谷、长短隧道、地下车库、高架桥等典型场景。
8.2 交付需求
-
交付融合定位引擎库文件及API文档。
-
交付GNSS/IMU驱动及配置参数。
-
交付定位子系统集成测试报告及性能标定报告。
9. 法律约束与标准遵从 (Legal Constraints and Standards Compliance)
9.1 法律法规
-
符合销售地关于地理信息数据采集、存储和传输的法律法规（如中国《网络安全法》、《数据安全法》）。
-
遵守欧盟《通用数据保护条例》（GDPR）关于位置隐私的规定。
9.2 标准要求
-
定位精度测试标准：遵循ISO 19116（地理信息 定位服务）相关方法论。
-
车规环境标准：满足AEC-Q100（芯片）及相应模块的可靠性要求。