双 Orin 高速公路自动驾驶系统架构设计方案

系统架构概述 (Dual Orin System Architecture Overview)

本方案采用双 NVIDIA Orin SoC 作为核心计算单元，结合车规级安全MCU（如英飞凌 AURIX TC397）实现高速公路/快速路场景下的自动驾驶。两个Orin分别担任主计算单元 (Orin A) 和备份安全单元 (Orin B) 的角色，功能上主从分工明确，决不采用同构的冗余运行。这种“一主一备”架构已成为L3及以上自动驾驶系统的主流做法：主SoC负责常规自动驾驶计算，备份SoC/MCU负责安全监控与紧急接管，当主计算单元发生故障时由备份单元接管控制执行安全停车。在硬件设计上，每颗Orin有各自独立的电源和接口，能够独立运行，并通过高速以太网连接彼此通信。同时配套的AURIX安全MCU作为最后一道关口，监测系统健康状态，在必要时介入控制实现最小风险机动 (MRM)。下图展示了双Orin系统的硬件架构和连接拓扑：

双Orin自动驾驶硬件架构示意图：Orin A为主计算SoC，Orin B为备份SoC。两者通过10Gb以太网高速链接（用于传感器数据/环境模型共享等）和低带宽CAN/MCU通道（用于心跳监测和控制指令交互）通信。Orin A获取全传感器数据并执行主要决策控制；Orin B获取选定的关键传感器信息并进行安全监控与应急规划。在正常运行中仅Orin A的控制指令经由安全MCU发送至线控底盘；当Orin A失效或感知崩溃时，Orin B接管控制，经由MCU触发车辆执行MRM安全停靠。

该架构充分利用双Orin总算力的同时，确保系统具备容错冗余和安全降级能力。例如，特斯拉FSD计算机配备的双SoC类似于飞机的双引擎，每个SoC各自运行不同的神经网络，从而充分利用算力并实现结果交叉验证。本方案中，两颗Orin也不会简单地运行相同算法做镜像热备，而是划分差异化的功能模块：Orin A运行完整的环境感知和决策规划主流程，Orin B运行精简的关键感知校验和应急控制流程。两者在正常情况下协同工作、互为监视，在异常情况下Orin B能够以降级模式接管车辆控制，实现安全过渡。这种主备架构既避免了冗余算力浪费，又满足功能安全对于单点失效的容错要求。系统满足车规功能安全需求（预期达到ASIL-D等级），并为将来引入QNX实时操作系统以进一步提升安全性预留了接口和划分空间。

主要硬件/软件构成如下：

主计算单元 Orin A (Drive Orin)：安装Linux OS，负责重载计算任务（多传感器感知、融合、预测、全局决策规划等），输出车辆控制计划。通过高速接口直连主要传感器，CAN接口连接安全MCU发送控制指令。
备份安全单元 Orin B (Drive Orin)：安装Linux OS（后期可切换/兼容QNX），负责冗余感知校核、安全监控和应急决策。获取部分关键传感器数据和Orin A共享的环境模型，通过以太网与Orin A同步状态；发生故障时执行MRM策略并向MCU发送备份控制指令。
安全微控制单元 AURIX MCU (ASIL-D)：独立于双Orin运行，作为安全岛。它聚合各节点状态（如Orin心跳、车辆姿态等），对来自Orin A的控制命令进行安全校验，通过底盘CAN执行转发控制；当检测到主系统故障或紧急情况时，自动进入最低风险状态，触发降级、警示驾驶员并控制车辆安全停车。
传感器与执行机构：包括多路摄像头、毫米波雷达、激光雷达、GPS/IMU定位模块等，通过GMSL2高速串行或以太网连接到Orin；线控底盘通过CAN接口由安全MCU控制。所有传感器数据时间同步，经时间戳统一（利用PPS或PTP），保证跨SoC数据融合的一致性。

总之，本架构在性能与安全之间取得平衡：利用双Orin的508 TOPS算力构建完整的感知决策系统，同时通过主备分工和MCU冗余机制确保系统任一部分失效时车辆依然能被安全地带入风险最低的状态。

模块划分与部署拓扑 (Module Breakdown and Deployment Topology)

软件系统按照自动驾驶通用流程划分为多个模块：感知、传感器融合、定位、预测、决策、规划、控制以及安全监控。结合双Orin架构的职责分配，各模块明确部署在Orin A或Orin B上运行，形成主备配合的拓扑。下表给出了主要功能模块的划分、部署位置、运行频率、主要输入输出及冗余关系：

模块功能	部署节点	预计频率	输入	输出	冗余设计及职责
环境感知 – 摄像头感知	Orin A	30 Hz帧率	前视&环视相机视频流 (GMSL2)	检测到的车辆、行人、车道线等目标列表	主感知通道，提供全面环境感知结果；Orin B有简化校验
环境感知 – 雷达/激光	Orin A	20 Hz	毫米波雷达点云、激光雷达点云 (以太网)	雷达障碍物列表、稠密点云	补充感知通道，提高对远距/侧向物体检测可靠性
多传感器融合	Orin A	20 Hz	摄像头目标、雷达目标、LiDAR点云	融合环境模型 (含多目标物体列表及轨迹)	主融合模块，整合同一时刻多源信息形成全局环境图
高精度定位	Orin A	10 Hz	GPS定位、IMU里程计、高清地图定位锚点	自车全局位姿（车道级定位）、速度姿态	主定位模块，提供车辆在地图坐标系下的精准位置；Orin B备用粗定位
运动预测	Orin A	20 Hz	融合环境模型（周围动态物体状态）	周围动态物体的未来轨迹预测	主预测模块，基于学习或模型预测前方车辆行为
决策规划 (正常行驶)	Orin A	20 Hz	环境模型、预测结果、高清地图路径	驾驶决策 (车道选择、跟车/变道指令)、局部规划轨迹	主决策与规划模块，负责正常驾驶策略计算
车辆控制	Orin A	100 Hz	规划轨迹、车辆状态	底盘控制指令 (转角、油门、制动)	主控制模块，高频执行横纵向控制输出；通过MCU发送CAN
安全监控	Orin B	10 Hz	Orin A状态心跳、环境关键信息(选取)	系统健康评估、故障告警，MRM触发信号	备份监控模块，低频监视主系统状态，检测感知或主SoC故障
应急决策与MRM规划	Orin B	10–20 Hz	基本环境信息 (关键障碍物、自车姿态)	安全停车策略(减速曲线、停车目标)	备份决策模块，主系统故障时激活，规划安全停靠的轨迹
备份感知校验 (简化感知)	Orin B	10–15 Hz	选定传感器数据 (如前向雷达、前摄像头)	关键目标/车道检测结果用于交叉验证	备份感知模块，常态下并行运行用于核对主感知的关键结果，防共模失效

表：双Orin系统主要软件模块的职责划分与部署。Orin A托管常规自动驾驶全流程，Orin B托管监控及应急相关模块。频率视算力及场景需求可动态调整。

如上所示：

感知模块 (Perception)：Orin A上运行多模态感知，包括摄像头视觉感知和雷达/激光雷达感知。摄像头感知模块处理来自前向和环视相机的图像流，以30Hz左右频率运行CNN模型检测车辆、行人、车道线等；雷达和LiDAR感知模块处理各自传感器数据，输出障碍物列表及点云。Orin B上并行运行一个简化感知用于校核：例如仅使用前向毫米波雷达或低分辨率前摄进行基本的障碍物检测，以低频获取关键危险物体信息，用于对主感知结果的交叉验证，防止主感知出现漏检或失效而无人察觉。这种多样化冗余可在很大程度上提高系统鲁棒性。
多传感器融合 (Fusion)：在Orin A上融合摄像头、雷达、LiDAR等多源信息。融合模块将视觉检测结果与雷达目标进行关联，过滤冗余，形成统一的环境模型（包含车辆周边静态地图元素和动态对象列表）。融合过程考虑各传感器时延，通过时间同步和坐标变换得到时空一致的结果。Orin B无需完整融合，仅提取Orin A共享的关键环境要素（如前车距离、最近障碍物），用于应急决策。
定位 (Localization)：在Orin A上运行高精度定位模块。利用差分GPS、惯导IMU以及车辆轮速里程计，并结合高精度地图匹配，实时解算车辆在车道级别的定位和姿态。频率约10Hz更新位置和航向，用于决策规划参考。若Orin A高精度定位失效，Orin B可基于原始GPS/IMU进行粗定位估算，以保障车辆在MRM过程中的自车位姿可用（不过高速场景下主定位需可靠运行，备份定位只作为兜底）。
运动预测 (Prediction)：在Orin A上，对周围移动的交通参与者（车辆、行人）进行轨迹预测。基于融合环境模型，使用基于运动学模型或学习的算法，估计每个目标未来几秒的运动轨迹（如相邻车辆是否有并线意图等）。预测模块输出提供给决策模块，用于更安全的规划。Orin B通常不独立运行复杂预测，但可在MRM时假定简单预测(例如假设前车匀速)来评估应急制动是否安全。
决策与规划 (Decision & Planning)：Orin A上负责正常自动驾驶决策规划。决策模块根据导航路线（来自高精地图或预设线路）以及环境感知结果，决定当前驾驶策略：保持车道巡航、跟车、超车变道等，高速场景下尤其关注车间距和换道决策。规划模块则根据决策生成具体的行车轨迹（如在本车道的速度曲线或变道路径），考虑乘坐舒适性和动态约束，以20Hz左右频率实时更新路径。规划出的局部轨迹发送给控制模块跟踪执行。Orin B在正常情况下并不参与正常行驶规划，而是在检测到主系统异常或接管条件下启动应急决策与MRM规划模块：此模块逻辑相对简单，以安全为首要目标。比如，若Orin A失效，Orin B决策立即减速保持本车道，并规划一条平缓停车轨迹（或如果环境允许，驶向应急车道停车）。这种应急规划不追求乘坐体验，而是强调可行性和安全冗余。在主系统工作正常时，Orin B保持此模块待命，并定期接收主轨迹以便在故障时可以参考最后已知轨迹/状态进行平滑交接。
车辆控制 (Control)：控制模块部署在Orin A上，以100Hz高频率运行，包括纵向控制（加速/减速）和横向控制（转向）。控制器根据规划轨迹和车辆当前状态（速度、姿态），采用控制算法（如PID、LQR或模型预测控制）计算油门开度、制动压力和转向角度命令。考虑到底盘为线控系统，Orin A通过CAN将控制指令发送至安全MCU，由MCU转发给底盘执行。在正常条件下，只有Orin A主动控制车辆。Orin B仅在主控制失效时才介入控制：此时备份控制模块激活，按照MRM轨迹发送MRM紧急控制指令（同样通过MCU经CAN下发，如紧急制动、保持方向）。MCU会监控两套控制命令，通常以主Orin A为主，当检测主指令超时或明显异常时，切换采用Orin B的备份控制指令。另外，MCU始终对最终输出的控制命令进行合理性校核（如制动过猛或转向过急时限幅），以防止因软件故障导致失控。
安全监控 (Safety Monitoring)：该模块是Orin B的核心常驻功能，低频运行但至关重要。它持续接收来自Orin A的健康信号（心跳、各模块运行状态）、以及环境关键数据（例如主感知识别的最近前车距离）。监控模块根据预设策略判断系统是否处于安全工作状态：如果发现感知失效（如环境模型长时间为空或传感器数据异常）、主决策/控制异常（如轨迹消失、控制超时）、或Orin A宕机（心跳丢失），则立即向系统发出故障告警并启动相应降级流程。一方面，监控模块通知MCU进入安全状态（MCU会提醒驾驶员接管并准备控制），另一方面触发Orin B自身的应急决策模块接管。安全监控还负责管理跨Orin通信的超时和数据校验，必要时可尝试重启或隔离故障模块。该模块相当于系统的“监理官”，确保整个软件栈按预期运作并第一时间响应异常。

上述模块划分和部署充分考虑了实时性和可靠性：计算负载大的感知和规划由Orin A承担，以利用其全算力达到高性能；安全相关的监控和备份控制由Orin B承担，保证在主SoC有难以察觉故障时仍有独立的硬件在运行健康检查。两颗Orin各模块通过明确的接口通信（见下节），使得模块间数据流动和职责边界清晰，每个模块的功能和开发任务都可以独立拆解出来交由不同工程师并行开发。

跨Orin通信设计 (Inter-Orin Communication Mechanism)

双Orin架构下的跨SoC通信是系统稳定高效运行的关键。我们设计了双通道通信机制：一个高带宽通道用于大量数据传输，另一个低带宽通道用于关键状态和控制信息传递，以同时满足数据吞吐和实时可靠要求。

高带宽通道 (High-BW Channel)：采用双Orin间的直连10Gb以太网链路（部分硬件平台也支持PCIe直连虚拟网卡），构成高速数据共享总线。该通道通过用户空间的以太网传输或零拷贝共享内存，传递大数据量的内容，例如Orin A输出的环境模型、部分原始/压缩传感器数据给Orin B，或者Orin B在特殊情况下请求关键传感器原始帧等。正常情况下，Orin B主要依赖自身直连的传感器或从Orin A订阅融合后的结果，而不需要复制全部原始数据，以节省带宽。但如果需要，10Gb链路能够支撑 ~GB/s 级的数据共享（实测单向接近4~9 Gbps）。通信中间件可使用零拷贝的发布-订阅框架（例如基于DDS的ROS2）或者定制的高效传输协议。我们将定义专门的高带宽Topic，如“融合环境模型”、“前视相机关键帧”等，由Orin A发布、Orin B订阅。当Orin A检测到Orin B接管需求时，也可通过此通道快速发送最近的传感器缓存数据，帮助Orin B更好地了解环境（例如提供最后一帧相机图像以辅助备份感知）。高带宽通道的延迟要求在几十毫秒以下，满足实时性。对于网络异常（如以太网故障），系统将日志记录并尝试重连，如果高带宽通道不可用且影响系统功能，则进入降级模式（仅凭各自已有信息运行，同时MCU报警）。
低带宽通道 (Low-BW Channel)：利用现有车载CAN/FlexRay总线或MCU中转，实现关键控制和状态信息的低延迟传递。具体包括：Orin A和Orin B定期通过MCU共享心跳和健康状态；当Orin B监测到Orin A故障时，通过MCU/CAN发送“主控故障接管”信号；Orin A也可通过MCU告知Orin B执行模式切换（如请求备份介入）。此外，MCU本身有多个CAN接口可以同时连接两颗Orin，实现双向备用通信。低带宽通道的数据量很小（字节级消息），但要求毫秒级延迟和高度可靠。因此，我们设计了简洁的通信协议：例如每隔50ms在MCU上汇总Orin A和Orin B的状态标志和重要标量（当前模式、故障码等），并在两个Orin间同步。该通道也用于控制权仲裁：MCU根据从两侧收到的“控制权标志”决定主/备控制指令哪一个生效。一旦Orin A心跳超时，例如100ms内未响应，则MCU判定主控失效，向Orin B发出“接管控制”指令。同样地，如果Orin B报告自身故障，MCU则通知系统降低自动驾驶等级或退出。低带宽通道通过冗余布线和错误检测（CRC校验等）确保消息的正确送达，任何通信错误都会立即触发报警并进入安全模式。

同步与时间戳：为了保证跨Orin数据融合的一致性，我们采用PPS（脉冲同步）信号或网络PTP精确对时，使两颗Orin共享统一的时钟。所有传感器数据在采集时打上时间戳，Orin A和Orin B使用该统一时间轴协调数据。例如，Orin B的备份感知可以从Orin A获取与自己关键帧时间最近的主感知结果进行比对。时钟同步精度可达微秒级，完全满足实时感知融合需求。

通信异常处理：双Orin通信需具备鲁棒性。如果高带宽链路发生异常（如带宽暴增延迟），Orin B将在监控中检测丢包率或延迟异常，必要时断开大数据订阅，仅依赖自身传感器和低频状态继续运行，并通知MCU。系统会在后台尝试恢复连接或降级功能范围。如果低带宽通道（MCU或CAN）故障，则情况更为严重：MCU无法获得双SoC状态，将根据失效模式采取措施，例如同时制动车辆并发出故障提示。所幸MCU与双Orin通常同板，且CAN总线简单可靠，此类失效概率极低。我们也在MCU中实现了监控双通信链路的看门狗，任何一方通讯异常都会记录故障码并提醒研发排查。

简而言之，跨Orin通信架构在带宽和实时性方面做到了统筹：高速以太网满足环境感知数据的共享需求，而低速MCU/CAN通道确保了安全信号的可靠传递和控制接管。两种通道互为补充，使双Orin系统内部的信息流动既高效又安全，为并行处理和故障切换奠定了基础。

故障处理与 MRM 降级策略 (Failure Handling and Minimal Risk Maneuver)

即使有完善的冗余设计，系统仍需面对各种故障场景，包括感知失效、主Orin计算故障、传感器异常等。我们制定了一套最小风险机动 (MRM) 降级策略，用于在发生故障时平稳地将车辆转移到安全状态。MRM策略涵盖故障检测、多级降级以及车辆安全停靠的全过程，可确保即使驾驶员未能立即接管，系统也能将风险降至最低。

下面的状态机描述了系统在正常运行、接管请求和MRM过程中的转换关系：

*自动驾驶系统故障降级状态机示意图：

在正常自动驾驶 (Normal ADS Operation) 下，Orin A主导车辆控制。若达到系统设计边界或即将超出ODD（运营设计域），系统向驾驶员发出接管请求 (Takeover Request)，此时自动驾驶仍维持，由驾驶员决定是否接管。如果驾驶员在允许时间内响应接管，则系统过渡为人工驾驶 (Driver Resumes Control)；若驾驶员无响应，则系统进入MRM主动模式 (MRM Maneuver Active)，由自动驾驶系统执行最小风险策略。在另一条路径中，若发生严重故障 (Critical Failure)（例如主Orin宕机或感知功能丧失），系统无需等待驾驶员，直接跳过接管请求进入MRM模式，由备份系统接管控制。MRM运行过程中车辆逐渐减速，并**安全停靠 (Safely Stopped)*于当前车道或路侧，完成最小风险条件 (MRC)。完成停靠后，自动驾驶功能完全退出，车辆保持停车且开启警示。该状态机体现了有驾驶员在场 (L3) 情况下的分层降级机制。

针对本项目的高速公路中巴应用，具体的MRM降级策略包括：

感知失效场景：如果Orin A的感知模块检测到前方环境“看不清”——例如摄像头遇到强光致盲或传感器数据空缺——系统会首先试图通过降级模式继续运行：降低车速，依赖有限的传感器（如雷达）维持基本车道保持。Orin B的安全监控会收到“感知数据不可信”信号，此时MCU向驾驶员发出请求接管的警示（声音告警+仪表提示），提示驾驶员尽快掌控车辆。如果驾驶员及时接管，则系统解除自动驾驶。如果驾驶员未响应且感知在短时间内无法恢复，系统将触发MRM：Orin B基于其可用的雷达/定位信息执行保守策略——通常是自动减速并在当前车道靠边停车。在此过程中，Orin B不尝试复杂变道，以免引入更多不确定，只通过稳健的纵向控制（如减速到20km/h以下）然后拉紧缓停至静止。整车会同时打开双闪警示灯。这个过程如果周边环境允许，也可规划驶入应急车道再停车，以更安全。感知失效引发的MRM通常属于有缓冲时间的降级，在减速过程中系统会不断监测感知是否恢复、驾驶员是否开始接管，若是则可中止MRM并将控制权移交驾驶员。
主Orin故障场景：主计算SoC Orin A一旦发生宕机、重启或不可恢复的软件错误（如进程崩溃导致长时间无心跳），这是最严重的故障，因为主感知和规划突然停止。我们采取立即MRM策略：Orin B通过监控迅速检测主心跳中断（100ms-200ms未响应），在<300ms内确认主故障。此时不要求驾驶员接管（因为人类不可能在零预警下在0.3秒接管），由Orin B直接接管控制执行MRM。具体动作是：假设当前车道前方安全（如果Orin A故障前有最后一次环境模型，可参考其中最近障碍距离；若无，则Orin B只能假定前方短距内无障碍），立刻自动减速。Orin B的应急决策模块将脱离巡航或跟车逻辑，转而生成一个紧急制动曲线，使车辆在合理距离内减速到安全速度并停车。同时MCU立刻打开双闪，并在车辆总线广播故障码通知其他ECU。由于主SoC故障可能导致部分传感器数据丢失，MRM过程中Orin B主要依靠自身还能获取的传感器（如直接连在Orin B上的前方雷达、定位仪）来监测车速和距离地面障碍物的信息。若在减速过程中发现前方有车辆慢速/静止，Orin B也会最大化制动以避免碰撞。如果主SoC故障时车速很高（如100 km/h），则MRM流程会尽可能线性减速，不急刹，保证稳定。车辆最终将在本车道停下或以低速持续爬行（如果完全停车不安全，可以低速行驶等待人工介入，但L3场景一般要求安全停车）。主Orin故障后的MRM属无缝接管：后备ECU完全替代主ECU执行驾驶任务直至停车。
其他故障场景：包括单一传感器故障（如某个雷达离线）、底盘指令异常、定位丢失等。对于不危及立即安全的部分功能失效，系统进入功能降级模式而非直接MRM。例如定位丢失可以靠视觉里程推算短期维持、单个摄像头故障则减少对该摄像头区域的依赖。这些情况下系统会通知驾驶员车辆性能受限，但可暂时继续自动驾驶。若多个关键传感器同时失效达到无法继续的程度，或者底盘不能执行控制，则系统将触发MRM或直接最安全策略（如如果转向失效只能减速拉手刹停）。总之每种故障都有预定的降级策略，优先级从高到低依次为：请求人工接管 > 自动降级运行 > 执行MRM安全停靠。

在整个MRM执行期间，MCU持续监控车辆状态，确保MRM策略本身的安全。如果在MRM过程中驾驶员突然介入（踩刹车/动方向盘），系统立即终止MRM，将控制权交给驾驶员，同时发出声音确认。MRM完成车辆停稳后，系统进入最低风险状态 (MRC)：此时引擎仍运行但车辆保持驻车，自动驾驶功能已解除，等待人工处理或道路救援。为了后续分析，每次故障和MRM事件都会记录日志。

我们的MRM设计遵循ISO 26262功能安全和ISO 21448预期功能安全(SOTIF)原则。这意味着我们不仅考虑硬件/软件失效，也考虑感知误判等功能局限导致的危险情景，并通过安全监控触发MRM，最大程度降低风险。总而言之，MRM降级逻辑确保无论是感知不可靠还是计算单元失效，车辆都不会失控地高速行驶，而是可预期地减速并停靠, 将潜在事故风险降至最低。

模块 MVP 实现与扩展路径 (Module MVP and Future Roadmap)

为确保方案可落地交付，我们为每个模块制定了最小可交付产品 (MVP) 实现方案，以及后续逐步升级的技术路线。MVP关注用最小代价实现基本功能，从而尽早验证闭环；在此基础上，再按照扩展路径逐步增强模块能力，以达到产品高阶要求。下面列出了主要模块的MVP实现要点和未来扩展方向：

感知模块：

MVP：采用单目前向摄像头结合简单的CNN模型实现车辆和车道线检测，满足基本的车道保持和前车跟随需求。雷达方面，集成1个前向毫米波雷达用于测距，实现自适应巡航车距控制。感知MVP仅关注最关键的前方区域目标，算法选择成熟开源模型（如YOLO车辆检测） fine-tune 后跑在Orin A上即可。数据融合层面MVP可以有限融合：比如将雷达测距结果与视觉前车检测做匹配，提高前车距离精度。
扩展：逐步增加环视相机和侧向传感器，实现360°环境感知；引入激光雷达提升对障碍物精确识别与测距，在更复杂场景（施工区、车辆插入等）保持可靠。算法方面替换为更高级的多任务感知模型（目标检测+分割+深度估计），部署在TensorRT上优化性能。增加多传感器融合算法，融合摄像头、雷达、LiDAR数据形成完整环境鸟瞰图，同时引入目标跟踪技术平滑感知输出。感知模块还将扩展对特殊目标（行人、摩托、异型车辆）和不良天气/夜晚的处理能力，并通过冗余感知（如双目视觉测距与雷达比对）提高可靠性。

传感器融合模块：

MVP：在传感器不多的情况下，MVP可采用简单规则融合：例如视觉和雷达各自输出前车的ID和距离，融合模块只需选取两者一致的前车目标用于后续控制。若仅单相机+单雷达，融合复杂度很低，可以暂不实现完整的空间融合算法。
扩展：随着摄像头像素提高和传感器增多，引入基于坐标转换和滤波的融合方法。使用EKF或UKF将多个传感器目标综合，并构建统一的障碍物列表和占用栅格。扩展多目标跟踪，在动态环境下稳定识别每一辆相邻车辆的轨迹。进一步的，高级方案可考虑基于AI的传感器融合（如BEV Bird-eye-view网络，将多相机图像和雷达点云输入同一深度网络输出环境表示）。融合模块也会增强对盲区、极端角度车辆的探测，通过V2X或传感器布局优化提高感知全覆盖。

定位模块：

MVP：利用RTK-GNSS + IMU提供车道级定位。在高速公路环境，MVP阶段高精地图可以暂不引入，通过高精度差分GPS得到<0.5m的定位精度满足车道保持即可。IMU用于插值提高姿态和短时失锁时的连续性。MVP中定位模块主要提供纵向位移（里程）校正和航向角，算法可使用开源的INS/GNSS融合库。
扩展：引入高清地图定位（车道线特征匹配或RSU定位），实现对特定道路要素（匝道、收费站）的识别。增加视觉SLAM或Lidar SLAM作为冗余定位，在GNSS遮挡时提供定位支撑。同时将定位频率提高并与感知融合，使车辆能准确定位到地图坐标系，支持更复杂的决策（如超车需考虑距离下个出口多少米）。未来还可融合差速里程计、5G定位等手段提高定位可靠性。定位模块还需考虑多传感器失效时的性能退化表现，符合功能安全要求。

预测模块：

MVP：采用简单运动模型进行预测。比如对前车的纵向运动，假设恒定速度或基于当前加速度作线性外推2秒，用于判断前车是否会减速。对相邻车道后方车辆，可简单假设其保持车道不变。这些规则模型尽管不够全面，但在高速场景基本满足“前车减速及时跟随、前车换道不激进超车”的需求。
扩展：引入学习型行为预测模型，利用深度学习根据车辆相对位置和动态历史预测其换道、加减速意图。例如训练RNN或Transformer网络输入周围车辆轨迹，输出未来轨迹分布。扩展预测到多种交通参与者（行人、摩托），虽然高速公路行人极少但应有检测。考虑车辆间交互（如旁车打灯可能并线）。高级预测模块可以输出带置信度的多模态轨迹供决策选择。还可结合V2V通信获取远距车辆意图（未来扩展）。

决策模块：

MVP：实现基本巡航决策：保持当前车道跟车，与前车保持安全距离（基于车距和相对速度计算），以及必要的自动减速（如前车减速或限速变化）。初始不执行自动变道，遇慢车则提示人工介入超车。通过这样的保守策略确保车辆能沿高速公路单车道平稳行驶。决策MVP可用状态机实现：状态包括巡航、跟车、减速停车（应对前方障碍或交通堵塞）。
扩展：逐步增加自动换道决策和匝道进出等行为。在有慢车的情况下，决策模块评估相邻车道空闲且安全距离足够时，发起超车换道决策。实现路线规划结合导航指引按需变道准备下高速。增加对车速调整的优化，如按限速上限行驶，主动调整速度以融入主车流等。决策策略从规则式升级为策略优化算法（如基于强化学习或场景树搜索），在更复杂场景下仍能做出安全高效决策。还需扩展异常处理策略：遇到施工区、事故等特殊事件时降级处理或请求人工。整个决策模块扩展要与功能安全结合，始终以安全优先，其次才是效率和舒适。

路径规划模块：

MVP：采用基于优化的轨迹跟随。对于保持车道情形，可简化为保持车辆当前航向，控制速度使前车距离稳定（纵向规划）。横向规划MVP基本为“居中当前车道”，除非决策命令变道。即MVP阶段规划只需在决策要求换道时生成一条目标车道线上的平滑插入轨迹，以及在需要停车时生成匀减速直线轨迹。算法可用简单的五次多项式曲线生成法，保证轨迹曲率连续以乘客舒适。
扩展：引入更复杂的轨迹优化：在纵横向同时优化的代价函数下生成轨迹，例如采用采样-评估或梯度优化的方法综合考虑安全距离、舒适度和偏离中心度。支持并行规划多条候选轨迹并打分选择，以便应对动态障碍绕行等。规划范围也扩展到全局路径和局部路径结合：如根据导航路径对局部轨迹加约束。进一步地，可结合机器学习/MPPI算法实时规划避障轨迹，提高对未知障碍物的反应。规划模块扩展要注意实时性，充分利用Orin GPU并行能力来加速采样计算，从MVP的20Hz提升到50Hz甚至更高，从而在高速行驶时提供更高频的轨迹刷新。

控制模块：

MVP：实现简单的PID控制器。针对转向，使用车道偏差作为输入的PID控制调整方向盘转角，针对速度，使用速度误差驱动纵向PID控制油门和刹车。初始标定基于直线道路匀速跟车场景调试，使车道偏离控制在±0.1m以内、车距误差±5%以内。控制模块MVP重点是打通“轨迹->车辆”的闭环，确保能稳定沿轨迹行驶，无振荡或延迟过大。考虑到底盘为线控且自带稳定系统，MVP控制可以相对简单。还需要加一个安全制动逻辑：一旦上层请求紧急停车或前方距离突减，立即切到刹车最大值制动。
扩展：引入模型预测控制(MPC)或其他高级控制策略，提高控制精度和平顺性。横向控制可加入前视模型，提高在曲线道路的响应。纵向控制可融合发动机制动力矩模型，优化换挡逻辑（若有）。同时考虑轮胎动力学和侧偏特性，针对高速工况防止车辆不稳定。扩展控制模块需和底盘进行大量联合标定测试。另一个扩展方向是容错控制：如果发现一侧执行器故障，控制算法自动调整分配（例如ESP干预）。当然这些和底盘厂协作实现。最终目标是车辆在各种速度和载重情况下，都能精确跟随规划轨迹，乘坐舒适且无多余振动冲击。

安全监控 & 冗余控制模块：

MVP：安全监控MVP聚焦心跳监测和故障切换。实现一个看门狗线程监控Orin A各主要进程定期发送的心跳消息，超时则判定故障。结合基础的传感器健康检查（如话题数据周期监控），一旦主系统卡死或数据停止，立即通过MCU触发报警和切换。冗余控制MVP则是简单的安全刹车：当确认主控失效时，Orin B直接输出一个恒定制动指令，使车减速停车。同时通过MCU指示打开双闪。该MVP确保最关键的“失控停下”功能。
扩展：安全监控将加入更多监测指标和智能判定。例如监控感知输出是否异常（连续N帧无障碍物则触发警告），监控决策是否迟缓（周期性检查决策是否更新）等，从多维度捕捉潜在问题。还会引入故障诊断系统，分类不同故障触发不同等级的降级措施，而不仅仅是直接紧急停车。冗余控制方面，扩展Orin B具备一定横向控制能力：例如当检测到车辆跑出车道时，即使主系统未完全失效，也可通过微调转向帮助纠正 (作为一种ADAS冗余)。同时，备份控制会更加智能：在主轨迹可用时，尽量跟随主轨迹；若不可用则采用预定模式停车。随着团队对系统理解加深，可实现双轨规划交叉验证：Orin A和Orin B各自独立计算轨迹，实时比对差异，若差异过大则说明可能有故障或环境不确定，可降低速度并警示。这将显著提高系统安全裕度，但也需要较高的算力和开发投入，属远期目标。

通过以上MVP和扩展规划，每个模块都可以循序渐进地演进。在早期阶段我们优先实现核心闭环功能以验证方案可行，然后依据测试中暴露的问题和需求，不断丰富各模块功能。这样的演进式开发既确保项目按期交付关键里程碑，又为后续性能提升留下空间。

并行开发与团队协作 (Parallel Development and Team Collaboration)

本方案特别考虑了适配6–10人规模团队并行开发的需求。在架构设计和模块划分时，我们注重模块的边界清晰和接口契约，使得各子团队或工程师可以相对独立地开发各自模块，而通过良好定义的接口实现系统集成。具体而言：

模块独立性与接口定义：上述各功能模块（感知、定位、决策等）都是松耦合、通过明确定义的数据接口连接。例如感知输出统一格式的ObstacleList消息，定位输出Pose消息，决策输出BehaviorCommand，规划输出Trajectory，控制输出ControlCmd等。我们将使用IDL(接口描述语言)或ROS2消息定义这些接口，在项目早期即确定消息结构和频率。各模块只需确保遵守接口契约收发数据，就能在真实或模拟数据下独立开发。这样，团队可将任务按模块分解：每人或每两人负责一个模块，无需等待其他模块完成即可开始各自开发。同时，公共的接口规范减少了团队沟通成本，避免集成时的对接问题。
开发流程与集成节奏：我们将采用迭代式开发和持续集成 (CI)。每个模块有自己的开发分支和测试用例，团队成员可以并行实现功能。在早期，会构建一个软件仿真框架，使各模块可以先在PC上以ROS2节点方式运行并通信，通过模拟传感器数据或记录的实车数据来调试验证。这允许并行开发而不必时时依赖实际车辆。CI系统将定期集成所有模块的最新版本，跑自动化测试（包括单元测试和仿真场景测试），及时发现接口不匹配或联调问题。这样避免最后整合才发现接口不符导致的大返工。
职责分工与协作：根据6–10人团队规模，可初步划分如下小组并行工作：

感知组 (2人)：一人主攻视觉感知算法开发，另一人负责雷达/LiDAR处理及多传感器融合，两人密切合作统一输出环境模型。
定位与建图组 (1人)：负责GNSS/IMU融合、地图标定及定位模块实现，同时提供定位结果给决策。
预测与决策组 (2人)：一人侧重运动预测模型开发，另一人负责决策策略和状态机，实现行车策略逻辑。
规划与控制组 (2人)：一人实现轨迹规划算法，另一人调试车辆纵横向控制和底盘接口，并协助实车标定。
系统集成与安全组 (1-2人)：专职负责安全监控模块、Orin间通信、中间件以及MCU接口开发，并制定故障注入测试。此组也担负整体系统集成，把各模块程序部署到双Orin平台并调优。
测试支持 (1人，可与他职复用)：编写模拟测试场景、仿真平台搭建，帮助各模块在仿真中验证。后期组织道路测试数据收集和分析。