273 lines
33 KiB
Markdown
273 lines
33 KiB
Markdown
---
|
||
tags: []
|
||
aliases:
|
||
- Project_Baseline 的深度补全
|
||
date created: 星期三, 十一月 19日 2025, 2:12:13 下午
|
||
date modified: 星期三, 十一月 26日 2025, 11:26:23 晚上
|
||
---
|
||
|
||
# Project_Baseline 的深度补全
|
||
|
||
## 1. 开发环境与构建生态 (Development Environment & Build Ecology)
|
||
|
||
- **核心指向**：确立代码“以此为基”运行的所有静态背景。包含操作系统底座、异构编译工具链的特殊性、以及依赖库的边界。
|
||
|
||
### 1.1 操作系统与内核基座 (OS & Kernel Baseline)
|
||
|
||
- **覆盖范围**：定义代码运行的最底层软件土壤。重点关注操作系统发行版的特定版本限制、Linux 内核参数配置、以及系统级基础库（如 libc/libstdc++）的兼容性边界。
|
||
- **1.1.1 发行版与内核版本指纹**
|
||
- 指向：具体的发行版元数据、内核发布号、补丁级别、以及内核构建时的 GCC 版本（防止 `insmod` 版本不匹配）。
|
||
- **1.1.2 内存子系统策略 (Memory Subsystem Policy)**
|
||
- 指向：大页内存（HugePages）配置、透明大页（THP）状态、虚拟内存交换策略（Swappiness）、Overcommit 策略。
|
||
- **1.1.3 CPU 调度与核心隔离 (CPU Scheduling & Isolation)**
|
||
- 指向：CPU 亲和性（Affinity）默认策略、隔离核心（Isolcpus）配置、NUMA 节点拓扑、实时调度策略限制。
|
||
- **1.1.4 系统级资源限制 (System Resource Limits)**
|
||
- 指向：文件句柄限制（Open Files）、栈空间大小（Stack Size）、最大进程数（NPROC）、核心转储（Core Dump）策略。
|
||
- **1.1.5 设备节点与总线映射 (Device Nodes & Bus Mapping)**
|
||
- 指向：PCIe 地址空间布局（BAR 空间）、设备文件权限（`/dev/*`）、IOMMU 组别状态，IO 调度算法 (I/O Scheduler)。
|
||
- **1.1.6 时间同步服务 (Time Synchronization)**
|
||
- 雷达系统涉及多板卡协同，OS 层面的时钟源（TSC/HPET）以及 `chrony`/`ptp4l` 的状态决定了打时标的精度。如果 OS 时间漂移，信号处理的时间对齐会出错。
|
||
|
||
### 1.2 异构编译工具链体系 (Heterogeneous Compiler Toolchain)
|
||
|
||
- **覆盖范围**：区分 Host 端 (CPU) 与 Device 端 (GPU) 的差异化编译路径。重点解决“谁来编译什么”以及“它们如何握手”的问题。
|
||
- **1.2.1 Host 端编译器规范 (Host Compiler Spec)**
|
||
- 指向：`g++` 的绝对路径、版本指纹、以及它所定义的默认 C++ 标准（`-std=c++11` vs `gnu++14`）。
|
||
- **1.2.2 Device 端编译器规范 (Device Compiler Spec)**
|
||
- 指向：`clang++` 的绝对路径、版本、**Corex 后端 Target 标志**（例如 `-x ivcore`）、以及它是如何被 CMake 识别的。
|
||
- **1.2.3 链接器与加载器配置 (Linker & Loader)**
|
||
- 指向：`ld` 版本、`rpath` 策略（确保运行时能找到 `libixattn.so` 等非标库）。
|
||
- **1.2.4 混合编译兼容性 (Hybrid Compilation Compatibility)** \<-- **新增**
|
||
- 指向：`clang++` 自动引用的 GCC Toolchain 路径（`--gcc-toolchain`）、C++ 标准库的一致性检查、以及强制定义的预处理宏（Macros）。
|
||
|
||
### 1.3 GPGPU 软件开发套件 (GPGPU SDK & Driver Stack)
|
||
|
||
- **覆盖范围**：不仅包含驱动和基础运行时，重点核查数学库、模板库及官方示例代码。
|
||
- **1.3.1 驱动核心模块状态 (Driver Kernel Modules)**
|
||
- 指向：`.ko` 模块加载参数、依赖关系（vfio-pci）、以及 `/dev` 设备节点的权限与映射。
|
||
- **1.3.2 运行时环境与兼容层 (Runtime Environment & Shim Layer)**
|
||
- 指向：`libcudart.so` 的版本伪装、`libcuda.so` (Driver API) 的存在性、以及动态链接库的真实物理位置。
|
||
- **1.3.3 管理与监控接口 (Management Interfaces)**
|
||
- 指向：`ixsmi` 工具的可用性、显存/算力占用查询指令、以及 ECC 错误统计接口（雷达长时运行必需）。
|
||
- **1.3.4 核心数学加速库 (Core Math Libraries)**
|
||
- 指向：**FFT (cuFFT)** 和 **BLAS (cuBLAS)** 库的具体存在性、版本号。这是雷达业务的“心脏”。
|
||
- **1.3.5 开发者头文件与生态 (Developer Headers & Ecosystem)**
|
||
- 指向：`cuda_runtime.h` 等头文件的位置、内容检查（是原版还是魔改版？），以及 **`thrust/`** 库是否存在。
|
||
- **1.3.6 官方示例与构建范式 (Official Samples & Build Patterns)**
|
||
- 指向：SDK 自带 Sample 代码的目录结构、Makefile 写法。这是 AI 学习“如何正确调用 SDK”的唯一真理来源。
|
||
|
||
### 1.4 构建系统与工程配置 (Build System & Project Configuration)
|
||
|
||
- **覆盖范围**：定义“源码 -\> 二进制”的自动化流水线。不仅包含 CMake 语法，更包含对异构编译器行为的**强制管控**。
|
||
- **1.4.1 CMake 核心环境与生成器 (CMake Core & Generator)**
|
||
- 指向：CMake 最低版本要求 (`cmake_minimum_required`)、生成器类型 (Unix Makefiles vs Ninja)、以及构建目录外构建 (Out-of-source Build) 的强制策略。
|
||
- **1.4.2 异构编译器编排策略 (Heterogeneous Compiler Orchestration)**
|
||
- 指向：**如何锁定 Host 编译器** (`CMAKE_CXX_COMPILER`)、**如何传递 Device 编译器路径** (`CLANG_CUDA_COMPILER`)，以及 `project()` 命令定义的语言范围（是仅 `CXX` 还是包含 `CUDA`）。
|
||
- **1.4.3 编译选项与性能开关 (Compilation Flags & Performance Switches)**
|
||
- 指向：
|
||
- **Host 端**：`-O3`, `-march=armv8-a+lse`, `-Wall`。
|
||
- **Device 端**：`-x ivcore`, `--cuda-gpu-arch`, `-fPIC`。
|
||
- **宏定义**：`NDEBUG`, `__ILUVATAR__` 等全局宏的管理。
|
||
- **1.4.4 依赖管理与链接逻辑 (Dependency Management & Linking Logic)**
|
||
- 指向：头文件搜索路径 (`include_directories` vs `target_include_directories`)、**RPATH 设定** (`CMAKE_INSTALL_RPATH`)、以及 `FindPackage` vs `FetchContent` (如 GTest) 的使用策略。
|
||
- **1.4.5 产物输出与安装规则 (Artifact Output & Installation Rules)**
|
||
- 指向：`CMAKE_RUNTIME_OUTPUT_DIRECTORY` (bin 目录)、`make install` 的行为、以及调试符号 (`.debug`) 的剥离策略。
|
||
|
||
### 1.5 核心依赖库与中间件 (Core Dependencies & Middleware)
|
||
|
||
- **覆盖范围**：除 OS 和 GPU SDK 外的第三方“军火库”。重点关注 Host 端算法支撑、数据链路传输、以及系统可观测性基础设施。
|
||
- **1.5.1 系统运行时与 ABI 基线 (System Runtime & ABI Baseline)**
|
||
- **核心指向**：这是二进制兼容性的底线。不仅要看 `glibc`，还要确认 `libstdc++.so` 包含的符号版本（`GLIBCXX_3.4.x`），防止引入的新库报 "version not found"。同时关注 `zlib` / `openssl` 等基础压缩加密库的版本。
|
||
- **1.5.2 Host 端信号处理与数学库 (Host Signal Processing & Math Libs)**
|
||
- **核心指向**：服务于 CPU 端的预处理/后处理算法。重点探测 **FFTW3**（是否存在？是否开启了 NEON 优化？）、**OpenBLAS** 或 **Eigen**。这些库的性能直接决定了 CPU 负载。
|
||
- **1.5.3 通信、存储与基础设施中间件 (Comm, Storage & Infra Middleware)**
|
||
- **核心指向**：服务于数据网关和系统健壮性。
|
||
- **通信**：ZeroMQ/DDS（传输层）、Protobuf/Flatbuffers（协议层）。
|
||
- **存储**：HDF5/Parquet（用于存原始回波）。
|
||
- **基建**：spdlog/glog（高性能日志）、yaml-cpp/jsoncpp（配置解析）。
|
||
|
||
### 1.6 调试、分析与版本控制工具 (Debugging, Profiling & Versioning)
|
||
|
||
- **覆盖范围**：涵盖从代码质量（内存安全）到性能验证（实时监控），再到大文件管理（Git LFS）的全周期辅助工具。
|
||
- **1.6.1 异构调试与内存安全 (Heterogeneous Debugging & Memory Safety)**
|
||
- **核心指向**：确保代码逻辑正确性与内存健壮性。
|
||
- **内容**：GDB 版本与**远程/异构配置**、C/C++ **内存检测工具（如 Valgrind）**、以及 IDE（如 VSCode）对 GPU 调试的集成状态。
|
||
- **1.6.2 性能分析与实时监控 (Performance Analysis & Real-time Monitoring)**
|
||
- **核心指向**：确保代码运行在正确速度并符合实时性要求。
|
||
- **内容**：GPU 专用 Profiler（如 `ixsmi` 高级功能）、**Linux 内核分析工具（Perf/ftrace）**、以及实时系统负载工具（`htop`、`numa` 监控）。
|
||
- **1.6.3 版本控制与数据基线管理 (Versioning & Data Baseline Management)**
|
||
- **核心指向**：确保工程版本与数据的一致性。
|
||
- **内容**：Git 版本、**Git LFS** (雷达数据/系数文件) 配置、CI/CD 环境中的版本标签规范。
|
||
|
||
---
|
||
|
||
---
|
||
|
||
## 2. 数据接口与通信协议 (Data Interface & Communication Protocols)
|
||
|
||
- **核心指向**：定义系统的“输入”与“输出”。包含前端 ADC 数据的接入方式、内部模块间的数据流转格式、以及对外的结果分发协议。
|
||
|
||
### 2.1 原始数据链路与采集协议 (Raw Data Link & Acquisition Protocol)
|
||
|
||
- **覆盖范围**：定义从雷达前端 ADC/DPU 发送至 Host 端的物理传输机制、链路协商、以及数据包的 L2/L3 层结构。重点关注 PCIe/万兆/自定义高速链路的适配和 JUMBO Frame 的支持状态。
|
||
- **2.1.1 物理链路层与传输媒介 (Physical Link Layer & Transport Medium)**
|
||
- **核心指向**：定义 Host 端 NIC（网络接口卡）或采集卡与前端 DPU/ADC 之间的物理连接类型和规格。涵盖光纤/铜缆 SFP 模块类型、端口速率（10G/40G/100G）、PCIe 链路的实际协商速度与带宽（GT/s, Link Width），以及链路协商的自适应或强制模式。
|
||
- **2.1.2 数据链路层协议与封装 (Data Link Layer Protocol & Encapsulation)**
|
||
- **核心指向**：定义数据流在 L2/L3 层的协议选择。涵盖是否使用标准 UDP/IP 协议，或者定制的裸 Ethernet/RoCE 协议。重点关注 **JUMBO Frame** 的最大有效载荷（MTU）设置，以及自定义协议头中对雷达单元 ID 和波束 ID 的封装格式。
|
||
- **2.1.3 NIC 硬件资源与队列管理 (NIC Hardware Resource & Queue Management)**
|
||
- **核心指向**：定义网络接口控制器（NIC）硬件的性能参数和配置。涵盖网卡 RX/TX **环形缓冲区（Ring Buffer）** 的深度配置、**中断聚合（Interrupt Coalescing）** 的延迟和计数阈值，以及 RX/TX 队列到 CPU 核心的亲和性（Affinity）绑定策略。
|
||
- **2.1.4 数据包完整性与时序保证 (Packet Integrity & Sequencing Assurance)**
|
||
- **核心指向**：定义在链路层对数据可靠性的保障机制。涵盖雷达数据包的**序列号（Sequence Number）** 字段、数据包头的 CRC/Checksum 校验、以及对传输层丢包率的实时监控与统计方法。
|
||
- **2.1.5 DMA 与内核旁路策略 (DMA & Kernel Bypass Strategy)**
|
||
- **核心指向**：定义从 NIC 硬件接收缓冲区将数据移动到用户态内存的高速策略。涵盖是否使用传统的内核 TCP/UDP 堆栈，还是采用 **DPDK**、**AF\_XDP** 或 **RDMA** 等内核旁路技术实现零拷贝（Zero-copy）的数据路径，以最小化 CPU 参与和内核延迟。
|
||
|
||
### 2.2 异构 DMA 与内存传输机制 (Heterogeneous DMA & Memory Transfer Mechanism)
|
||
|
||
- **覆盖范围**：定义 Host CPU 与 Device GPU（智铠 MR-V100）之间的高速、低延迟数据移动策略。重点关注 **零拷贝（Zero-copy）**、**UVA** (统一虚拟寻址) 的利用、以及对 **NUMA 拓扑**的感知，以优化 Node 1 显存访问性能。
|
||
- **2.2.1 锁页内存管理与分配策略 (Page-Locked/Pinned Memory Management)**
|
||
- **核心指向**：定义 Host 端内存的分配方式以适配 DMA 引擎。涵盖使用 `cudaMallocHost` 或 `cudaHostRegister` 申请**锁页内存（Pinned Memory）**，以规避 OS 分页机制导致的 DMA 拷贝性能下降。对于雷达高吞吐业务，需定义专用的大块内存池（Memory Pool）以减少频繁申请/释放的系统调用开销。
|
||
- **2.2.2 异步流水线与计算通信重叠 (Asynchronous Pipelining & Compute-Copy Overlap)**
|
||
- **核心指向**：定义如何利用 GPU 的独立 Copy Engine 实现“掩盖传输延迟”。涵盖 **CUDA Streams** 的多流设计模式，实现 `H2D` (Host-to-Device) 拷贝、`Kernel` 计算、`D2H` (Device-to-Host) 拷贝的三级流水线并行（Ping-Pong / Double Buffering）。
|
||
- **2.2.3 NUMA 感知的内存亲和性控制 (NUMA-Aware Memory Affinity Control)**
|
||
- **核心指向**：针对双路飞腾 S5000C 的特殊架构，定义内存物理位置的约束。强制要求与 GPU 交互的 Host 内存必须分配在 **NUMA Node 1**（即 GPU 所挂载的 CPU 插槽）的本地 DRAM 上，严禁跨 QPI/UPI 总线进行 DMA 传输，以避免带宽减半和延迟抖动。
|
||
- **2.2.4 统一虚拟寻址与零拷贝技术 (Unified Virtual Addressing & Zero-Copy)**
|
||
- **核心指向**：利用 Iluvatar SDK 的 UVA 特性，定义特定场景下的免拷贝访问策略。涵盖对于小数据量（如控制参数、波控码）直接让 GPU 通过 PCIe 总线读取 Host 内存（Zero-Copy），以及评估在大数据量回波传输中启用 UVA 的 TLB Miss 风险与收益。
|
||
- **2.2.5 传输粒度与 TLP 效率优化 (Transfer Granularity & TLP Efficiency)**
|
||
- **核心指向**：定义 DMA 传输的最小数据块大小（Batch Size）。基于 PCIe 协议的 **TLP (Transaction Layer Packet)** 开销和 **MPS (Max Payload Size)** 限制（审计发现仅 128/256 Bytes），计算最优的传输粒度（如按 CPI 或 Pulse Batch），以最大化 PCIe 有效载荷比率。
|
||
- **2.2.6 显存布局与对齐约束 (VRAM Layout & Alignment Constraints)**
|
||
- **核心指向**：定义数据在显存中的物理排列。涵盖满足 GPU 内存控制器 **Coalesced Access (合并访问)** 要求的首地址对齐（通常为 128/256 字节对齐）、Padding 填充策略，以及多通道雷达数据的存储格式（SoA vs AoS）转换逻辑，以适配 SIMT 计算模式。
|
||
|
||
### 2.3 内部控制平面通信接口 (Internal Control Plane Interface - IPC)
|
||
|
||
- **覆盖范围**：定义系统内部各功能模块（`IModule`）与核心管理组件（调度器、配置管理器）之间的**控制流交互机制**。该接口基于**进程内事件总线（In-Process EventBus）**架构，实现模块间的解耦、生命周期编排、资源仲裁及故障传递。**核心约束**：控制平面严禁传输任何业务数据块（如 I/Q 数据或点迹数组），仅允许传输元数据、状态码和控制指令。
|
||
- **2.3.1 事件总线架构与路由机制 (Event Bus Architecture & Routing Mechanism)**
|
||
- **核心指向**：定义系统控制流的中枢神经。采用**发布 - 订阅 (Pub/Sub)** 模式，实现 `IEventBus` 接口。支持**同步分发**（`publishSync`，用于高优先级指令的即时回调）与**异步分发**（`publishAsync`，用于状态上报的非阻塞入队）的混合路由策略，确保控制指令在微秒级内准确送达。
|
||
- **2.3.2 全链路追踪上下文传递 (Trace Context Propagation)**
|
||
- **核心指向**：定义控制指令的审计与追踪规范。强制要求所有控制事件（Event）必须携带全局唯一的 `TraceID`。涵盖在跨线程（如从 `API网关` 线程到 `SignalProcessor` 工作线程）传递事件时，利用 `TraceContextGuard` 或类似的 **RAII 机制**自动捕获、保存和恢复线程本地存储（TLS）中的追踪上下文，实现“无感”的链路追踪。
|
||
- **2.3.3 生命周期编排与状态同步协议 (Lifecycle Orchestration & State Synchronization)**
|
||
- **核心指向**：定义 `TaskScheduler` 与业务模块间的握手协议。涵盖标准化的生命周期指令事件（`StartModuleEvent`, `StopModuleEvent`, `PauseModuleEvent`）以及模块的状态变更回执（`ModuleRunningEvent`, `ModuleStoppedEvent`）。重点关注在系统启动/关闭时的**拓扑依赖顺序**控制逻辑，确保无“悬空”状态。
|
||
- **2.3.4 故障传播与恢复信令 (Fault Propagation & Recovery Signaling)**
|
||
- **核心指向**：定义异常情况下的通信契约。涵盖**致命错误上报**（`ModuleFailedEvent`，携带标准化 `ErrorCode` 和堆栈快照）的格式，以及调度器下发的**恢复指令流**（如 `PauseDataFlow` -> `RestartModule` -> `ResumeDataFlow`）的时序规范。集成**熔断器（Circuit Breaker）**状态广播，防止故障扩散。
|
||
- **2.3.5 系统负载保护与热节流控制 (System Load Protection & Thermal Throttling)**
|
||
- **核心指向**：鉴于显控架构的扁平化，控制平面的资源管理重心从“UI 响应性保障”转移至 **“系统物理安全保障”**。接口仅用于在极端工况（如机箱温度过高、GPU 功耗触顶）下，强制降低计算负载以保护硬件。
|
||
- **2.3.6 两阶段配置热更新协议 (Two-Phase Configuration Hot-Reload Protocol)**
|
||
- **核心指向**：定义动态配置变更时的协商机制。涵盖 `ConfigManager` 发起的 **“验证询问”**（`ValidateConfigChangeEvent`，模块需在超时前反馈可行性）和 **“变更通知”**（`ConfigChangedEvent`，模块执行原子更新），确保在并发环境下配置更新的事务一致性。
|
||
- **2.3.7 性能指标遥测通道 (Performance Telemetry Channel)**
|
||
- **核心指向**：定义业务模块向 `MonitoringModule` 上报健康数据的单向通道。涵盖 `MetricsUpdateEvent` 的数据结构定义（键值对映射），以及采用 **线程本地缓存（Thread-Local Storage）** 结合 **MPSC（多生产单消费）队列** 的高吞吐、无锁上报策略，彻底消除监控逻辑对业务主线程的锁竞争干扰。
|
||
|
||
### 2.4 外部目标数据分发协议 (External Target Data Distribution Protocol)
|
||
|
||
- **覆盖范围**：定义核心处理服务器（通过 `DisplayController`）向外部独立显控终端分发高实时性业务数据（如航迹、点迹）的**网络通信契约**。鉴于显控端采用轻量级 2D 渲染，本协议不再包含针对 UI 交互的流控逻辑，而是专注于**全速、单向、无阻塞**的数据推送，仅在接收到系统级热保护指令时执行被动节流。
|
||
- **2.4.1 传输层拓扑与套接字模型 (Transport Layer Topology & Socket Model)**
|
||
- **核心指向**：定义数据传输的物理载体。采用 **UDP 单播 (Unicast)** 模式，由服务器作为发送方，向单一客户端推送。强制使用 **非阻塞 (Non-blocking) Socket** 配合 `epoll` 边缘触发模式。鉴于已移除 UI 抢占逻辑，Socket 发送缓冲区 (`SO_SNDBUF`) 应配置为**最大可用值**（如 8MB+），以吸收网络抖动，确保在计算核心全速运转时网络层不成为瓶颈。
|
||
- **2.4.2 业务数据序列化规范 (Business Data Serialization Specification)**
|
||
- **核心指向**：定义跨网络二进制格式。继续强制使用 **Google Protobuf (v3)**。数据包根对象 `TrackDataBatch` 必须包含**全链路追踪 ID (`TraceID`)**。由于取消了任务切分，数据包的生成频率将与雷达脉冲处理周期（CPI）严格同步，不再出现因被抢占而导致的“微批次（Micro-batch）”碎片化数据包。
|
||
- **2.4.3 丢包检测与时序完整性机制 (Packet Loss Detection & Sequencing Integrity)**
|
||
- **核心指向**：定义数据一致性策略。协议头包含单调递增的 **`batch_sequence_id`**。客户端对于乱序包执行**立即丢弃**策略。由于后端不再因 UI 操作而暂停，客户端应预期收到**极其平稳**的数据流；任何超过 2 个周期的静默都应被客户端判定为“网络故障”而非“后端繁忙”，并触发重连告警。
|
||
- **2.4.4 热节流响应与流量整形 (Thermal Throttling Response & Traffic Shaping)**
|
||
- **核心指向**：**（基于 ECN 修正）** 定义在系统过热时的降级行为。当 `DisplayController` 收到 `SetComputeThrottleEvent`（热保护指令）时，必须在网络发送层执行**主动丢包**或**发送间隔插入（Gap Insertion）**，以减少网卡中断和总线功耗。例如，在 `Level 2` 节流状态下，仅发送关键航迹数据（Confirmed Tracks），丢弃所有点迹（Plots）和调试数据，从而降低系统整体热负荷。
|
||
- **2.4.5 端到端延迟遥测 (End-to-End Latency Telemetry)**
|
||
- **核心指向**：定义性能监控闭环。数据包必须携带 **“数据生成时间戳”**。客户端计算 **Glass-to-Glass Latency** 并回传。此指标现在主要用于监控网络链路质量和散热系统的有效性（即观察热节流是否导致了延迟显著增加），而非用于调节 UI 渲染优先级。
|
||
|
||
---
|
||
|
||
**变更说明 (基于 ECN-2025-001)：**
|
||
1. **移除**：移除了所有关于“为了 UI 响应性而暂停数据发送”的描述。
|
||
2. **新增**：**2.4.4 热节流响应**。这是新架构下唯一合法的“主动降速”场景。
|
||
3. **调整**：在 **2.4.1** 中强调了 Socket 缓冲区配置为“最大值”，因为不再需要担心缓冲区积压影响 UI 线程（UI 线程已与计算/发送线程物理解耦且互不干扰）。
|
||
|
||
**下一步交互建议：**
|
||
我们已完成基于 ECN 补丁修正的 **2.4 外部目标数据分发协议**。请指示：我们是继续进行 **3. 信号处理算法与数学原理** 的分解，还是您有其他的 ECN 需要应用？
|
||
|
||
### 2.5 数据结构定义与序列化规范 (Data Structure Definition & Serialization Specification)
|
||
|
||
- **覆盖范围**：定义系统内外部数据交互的**静态契约**。该规范严格区分 **“内部原生对象（In-Memory Native Objects）”** 与 **“外部传输契约（On-Wire Contracts）”**，并界定两者之间的**转换边界**。内部关注极致的计算性能（SIMD 对齐、零拷贝），外部关注跨语言/跨平台的互操作性（Protobuf）。
|
||
- **2.5.1 内部高性能业务对象模型 (Internal High-Performance Business Object Model)**
|
||
- **核心指向**：定义在 `DataReceiver` -> `SignalProcessor` -> `DataProcessor` 流水线中流转的 C++ 原生结构体（DTO）。涵盖 `DetectionResult`（点迹）和 `TrackData`（航迹）的内存布局设计，强制使用 **POD (Plain Old Data)** 类型，并应用 `alignas(16/32)` 以适配 **SIMD (AVX/NEON)** 向量化指令优化，严禁在核心计算路径上使用虚函数或复杂对象。
|
||
- **2.5.2 内部控制事件模式定义 (Internal Control Event Schema Definition)**
|
||
- **核心指向**：定义在 `EventBus` 上流转的控制信令结构。所有事件必须继承自 `BaseEvent`，并强制包含 **全链路追踪 ID (`TraceID`)** 和 **高精度时间戳**。事件负载（Payload）必须保持轻量（通常仅包含状态码、配置键值对或对象 ID），严禁携带大块业务数据（如 I/Q 波形），以保障控制平面的低延迟响应。
|
||
- **2.5.3 外部数据交换契约 (External Data Exchange Contract)**
|
||
- **核心指向**：定义系统向外部（显控终端、API 网关）输出数据的接口定义语言 (IDL)。强制选用 **Google Protobuf (v3)** 作为唯一标准。涵盖 `.proto` 文件的版本管理规范（语义化版本控制），以及字段的 **向前/向后兼容性** 设计原则（如使用 `optional` 字段，保留 `reserved` 标识符），确保前后端可独立演进。
|
||
- **2.5.4 零拷贝数据容器规范 (Zero-Copy Data Container Specification)**
|
||
- **核心指向**：定义承载内部业务对象的通用包装器 `DataPacket<T>`。涵盖其 **Header** 的标准化元数据（序列号、源模块、TraceID），以及 **Payload** 的所有权管理机制——必须使用 `std::unique_ptr` 配合 **自定义删除器 (Custom Deleter)**，以实现内存块在生命周期结束时的自动归还（回收到 `MemoryPool`），彻底消除内存泄漏风险。
|
||
- **2.5.5 序列化边界与映射策略 (Serialization Boundary & Mapping Strategy)**
|
||
- **核心指向**：定义“内部对象”转换为“外部格式”的**唯一合法位置**。明确规定 **仅在 `DisplayController`（数据网关）** 和 **`ApiCommandService`（API 响应）** 处进行序列化操作。涵盖从 C++ Struct 到 Protobuf Message 的字段映射逻辑（Mapping Logic），以及在边界处进行 **数据清洗与脱敏** 的安全规范。
|
||
|
||
### 2.6 时序同步与数据一致性 (Timing Synchronization & Data Coherence)
|
||
|
||
- **覆盖范围**：定义系统的时间基准获取方式、数据流打点策略以及跨模块处理时的时间对齐逻辑。涵盖从硬件层面的 PTP/GPS 同步，到软件层面的 CPI（相干处理间隔）对齐，以及航迹预测中的时间外推算法，确保系统在微秒级精度下的时空一致性。
|
||
- **2.6.1 高精度统一时钟源架构 (High-Precision Unified Clock Architecture)**
|
||
- **核心指向**：定义系统时间的唯一真值来源。优先采用 **PTP (IEEE 1588v2)** 协议通过网口同步至 GPS/北斗授时服务器，实现亚微秒级的时间同步精度。涵盖在 PTP 不可用时的 **NTP 回退策略**，以及利用 CPU **TSC (Time Stamp Counter)** 寄存器作为高频计时源的校准逻辑，防止系统时间跳变（Time Jump）导致的逻辑错误。
|
||
- **2.6.2 多级数据打点策略 (Multi-Level Timestamping Strategy)**
|
||
- **核心指向**：定义数据包时间戳的生成位置与精度分级。首选网卡硬件 **TSU (Timestamp Unit)** 生成的入站时间戳（Ingress Timestamp），次选内核网络栈的 `SO_TIMESTAMP` 软件时间戳。在 `DataReceiver` 封装 `RawDataPacket` 时，强制将此硬件/内核时间戳固化为数据的 **“诞生时间” (Generation Time)**，并在后续全链路中保持不变。
|
||
- **2.6.3 相干处理间隔对齐机制 (CPI Alignment Mechanism)**
|
||
- **核心指向**：针对信号处理模块的特殊时序要求。定义如何根据雷达 **PRF (脉冲重复频率)** 和 **波位编码**，将连续到达的 UDP 数据包在内存池中重组为严格对齐的 **CPI 数据块**。涵盖处理网络抖动导致的脉冲到达时间波动（Jitter）的缓冲策略，确保 FFT 和多普勒处理时的数据在时间域上严格相干。
|
||
- **2.6.4 航迹外推与异步测量融合 (Track Extrapolation & Asynchronous Measurement Fusion)**
|
||
- **核心指向**：针对数据处理模块的时空一致性逻辑。定义在进行数据关联（Data Association）时，如何将上一时刻（$t_{k-1}$）的航迹状态，基于运动模型精确外推至当前测量时刻（$t_k$）。涵盖处理乱序到达（Out-of-Order）量测数据的**延迟关联**或**丢弃策略**，确保卡尔曼滤波的更新步基于单调递增的时间轴。
|
||
- **2.6.5 全链路延迟审计与抖动监控 (End-to-End Latency Auditing & Jitter Monitoring)**
|
||
- **核心指向**：定义系统实时性的度量标准。利用 `DataPacket` 头部携带的诞生时间戳，在流水线的每个关键节点（接收、信号处理完成、航迹更新完成、网关发送）计算 **驻留时间 (Residence Time)**。监控模块需实时统计各阶段的延迟分布，一旦发现处理抖动超过 CPI 周期的一定比例（如 10%），立即触发性能告警或热节流保护。
|
||
|
||
### 2.7 链路鲁棒性与错误校检 (Link Robustness & Error Checking)
|
||
|
||
- **覆盖范围**：定义系统对通信链路故障的容错能力。涵盖在 UDP 链路中部署 CRC/Checksum 校验、丢包统计与报告机制、以及内部 IPC 异常时的超时和重试策略。
|
||
- **2.7.1 应用层数据完整性校验 (Application-Layer Data Integrity Verification)**
|
||
- **核心指向**：弥补 UDP 标准校验和（16-bit）在大数据量传输下的碰撞风险。确立 **CRC32c (Castagnoli)**（硬件指令加速）为标准算法，强制在所有 `TrackDataBatch` 和 `RawDataPacket` 的协议头中包含校验字段。定义校验失败时的**“零容忍”丢弃策略**，防止比特翻转（Bit Flip）导致的脏数据污染卡尔曼滤波状态。
|
||
- **2.7.2 链路健康度监测与心跳机制 (Link Health Monitoring & Heartbeat Mechanism)**
|
||
- **核心指向**：定义双向链路的保活协议。在数据静默期（无业务数据发送时）强制发送 **高频心跳包 (1Hz - 10Hz)**，以维持中间网络设备的 NAT 映射并快速检测物理断连。定义 **“静默超时” (Silence Timeout)** 阈值（如 2000ms），一旦触发即判定链路中断，自动触发告警并重置接收状态机。
|
||
- **2.7.3 差异化丢包恢复策略 (Differentiated Packet Loss Recovery Strategy)**
|
||
- **核心指向**：针对不同业务流性质定义恢复逻辑。对于 **实时雷达数据（Data Plane）**，采用 **“即时丢弃 (Drop-and-Forget)”** 策略，严禁重传以避免队头阻塞（Head-of-Line Blocking）；对于 **关键控制指令（Control Plane）**，采用 **“带确认重传 (ARQ / ACK-Retry)”** 机制，确保配置变更和启停指令的必达性。
|
||
- **2.7.4 内部 IPC 拥塞控制与背压 (Internal IPC Congestion Control & Backpressure)**
|
||
- **核心指向**：针对进程内 `SPSC`（无锁队列）的溢出保护。定义 **“有界队列 (Bounded Queue)”** 策略，当队列深度达到高水位（High Watermark，如 80%）时，对上游模块施加**背压 (Backpressure)**，强制执行 **“尾部丢弃 (Tail Drop)”** 或 **“间隔抽稀”**，优先保障系统主进程不发生 OOM（内存溢出）。
|
||
|
||
---
|
||
|
||
---
|
||
|
||
## 3. 异构计算架构与资源调度 (Heterogeneous Computing & Resource Scheduling)
|
||
|
||
- **覆盖范围**：从任务模型的定义，到 CPU/GPU 的分工，再到显存内部的精细化管理。核心目标是在 Feiteng + Iluvatar 平台上实现 **“数据进，结果出，中间无阻塞，显存不碎片”** 的极致流水线。
|
||
|
||
### 3.1 异构协同模型与职责边界 (Heterogeneous Collaboration Model & Responsibility Boundary)
|
||
|
||
- **核心指向**：明确 Host (CPU) 与 Device (GPU) 的绝对分工。确立 **“控制密集型在 CPU，计算密集型在 GPU”** 的原则。定义 CPU 不再是“保姆”（微观管理每个 Kernel 的启动），而是“指挥官”（下发宏观指令包）。界定后处理（CFAR 之后的数据关联）回流 CPU 的具体边界点，防止 GPU 算力被标量逻辑浪费。
|
||
|
||
### 3.2 计算图静态编排与执行引擎 (Static Compute Graph & Execution Engine)
|
||
|
||
- **核心指向**：针对雷达算法流程固定的特性，摒弃运行时动态解析 DAG（有向无环图）的高开销模式。定义 **“静态编译图 (Static Compiled Graph)”** 策略，在系统初始化阶段将业务流程固化为一系列预定义的 `TaskNode` 链表。执行引擎（Execution Engine）仅需按序触发，实现 **零开销调度 (Zero-Overhead Scheduling)**。
|
||
|
||
### 3.3 GPU 上下文与流并发策略 (GPU Context & Stream Concurrency Strategy)
|
||
|
||
- **核心指向**：定义如何利用智铠 GPU 的硬件队列（Hardware Queues）。鉴于 ECN-2025-001 已移除 UI 抢占，本节确立 **“通道级并行 (Channel-Level Parallelism)”** 策略。即每个雷达通道（或波束）绑定一个独立的 `cudaStream_t`，实现多通道算法的物理并行执行，最大化 GPU 占有率（Occupancy）。
|
||
|
||
### 3.4 显存暂存区与工作空间管理 (VRAM Scratchpad & Workspace Management)
|
||
|
||
- **核心指向**：解决算法中间结果（如脉压后的复数矩阵）的存储问题。严禁在热路径上调用 `cudaMalloc`。设计 **“显存竞技场 (VRAM Arena)”** 或 **“栈式分配器 (Stack Allocator)”**，为每个流预分配固定的临时工作区（Scratchpad）。利用内存复用技术（Memory Aliasing），让不同阶段的算法共享同一块物理显存，极大降低显存峰值开销。
|
||
|
||
### 3.5 内核启动优化与持久化线程 (Kernel Launch Optimization & Persistent Threads)
|
||
|
||
- **核心指向**：对抗 PCIe 启动开销（Launch Latency）。针对大量微小算子（如简单的向量加减），引入 **“内核融合 (Kernel Fusion)”** 策略或 **“持久化线程 (Persistent Threads)”** 模式（即 GPU 上常驻一个 Loop Kernel，通过轮询标志位执行任务），消除 CPU 频繁下发指令带来的系统调用抖动。
|
||
|
||
### 3.6 异构同步机制与完成通知 (Heterogeneous Synchronization & Completion Notification)
|
||
|
||
- **核心指向**：定义 CPU 如何感知 GPU 计算结束。摒弃高延迟的 `cudaStreamSynchronize()`（全阻塞），采用 **“基于事件的回调 (Event-Based Callback)”** 或 **“主机轮询标志位 (Host-Polling on Zero-Copy Flag)”** 机制。与 2.3.1 的事件总线对接，在计算完成的微秒级内触发下游的 `DisplayController`。
|
||
|
||
---
|
||
|
||
---
|
||
|
||
## 4. 信号处理业务逻辑流 (Signal Processing Business Logic Flow)
|
||
|
||
- **核心指向**：定义软件需要实现的“业务链路”。即数据在进入流水线后，需要经过哪些具体的处理节点（Node）以及这些节点的连接顺序和控制逻辑。
|
||
|
||
---
|
||
|
||
## 5. 实时性能与吞吐量约束 (Real-time Performance & Throughput Constraints)
|
||
|
||
- **核心指向**：定义系统的“非功能性指标”。包含对处理时延的硬性要求、数据吞吐带宽的限制、以及系统优化的量化目标。
|
||
|
||
---
|
||
|
||
## 6. 工程架构与可靠性保障 (Engineering Architecture & Reliability Assurance)
|
||
|
||
- **核心指向**：定义系统的“健壮性”。包含程序的生命周期管理、错误处理机制、日志系统、以及在无人值守情况下的自恢复能力。
|