辅助驾驶域控一个背景之后，是两种文化-下｜盖世大学堂辅助驾驶域控系列知识讲解

一、系统架构设计的核心思路：拆分与权衡

从Mobileye在安全边界上的设计来看，其采用的是两种独立系统相互解耦的思路：一个纯视觉系统用于快速迭代，一个激光雷达和雷达系统用于边界控制，且两个系统分别进行功能安全设计。而行业内常见的做法是将多传感器耦合在一个系统内，若要满足ASIL-D的安全等级，需对整个系统施加安全设计。

以摩拜的设计为例，其架构显著体现了上述独立系统的设计理念。在实际操作中，视觉系统常以激光雷达数据作为增值数据，但多数架构设计倾向于将所有元素融合到单一模块中。Mobileye与行业常规设计的对比，反映出其在架构设计上的独特思考——这种思考并非停留在表面的图示差异，而是深层设计逻辑的体现。

在架构设计中，人们往往本能地遵循“物尽其用”的原则，倾向于整合所有资源。但Mobileye的设计思路并非如此，它更注重挖掘有潜力的部分以实现降本。例如，仅使用摄像头的纯视觉系统在零部件质量、后期控制及成本控制等方面更具潜力。从第一性原理来看，纯视觉系统的功能实现具有可行性，代表着未来系统的发展方向。同时，为满足短期内工程量产与交付的需求，激光雷达和雷达系统可作为“兜底”保障。这种设计思路正是该案例的核心价值所在。

这种将系统拆分为不同功能模块的思想并非个例，在通讯、功能级别、MCU/MPU级别等多个维度均有体现。当具备这种拆分思想后，架构设计会呈现出不同的逻辑；若未意识到这种差异的重要性，仅追求资源的集中利用，最终会陷入安全与体验的平衡困境。

在系统设计中，平衡安全与体验的需求往往需要进行权衡。例如，既要求系统安全可靠，又希望其具备良好的用户体验，这些要求通常会集中施加于单一系统。但从Mobileye的设计逻辑来看，其在实现过程中对这种平衡有着深刻的考量，这也是值得推崇的设计思路。

二、开发风格与系统迭代的分离策略

从不同类型的开发风格来看，MPU与MCU呈现出显著差异。MPU倾向于独立运作、系统级解耦，关联云端的数据管道、远程诊断、自动训练等快周期任务，涉及多数感知单元和少数执行单元；MCU则侧重慢周期任务，与车端安全部件相关，涉及少数感知单元和多数执行单元。

为应对敏捷开发与功能安全的要求，系统设计需采用快慢迭代分离的策略。云端开发分为服务敏捷的快周期自动化迭代和服务安全性设计的慢周期迭代，功能安全系统与功能实现系统构建弱耦合关系，通过控制权切换实现协同。

在传统业务系统中，车云两端业务通常是分割的。对于控制器，软件工程会区分功能安全系统和功能体验系统的迭代链路。业务系统一般包含配置和诊断，配置涉及软件集成时的设置，诊断则与传统汽车行业的DTC相关。安全系统和云端数据类业务可分别形成闭环，且安全系统对功能实现系统具有仲裁权。这种设计虽常见，但随着系统复杂度提升，新从业者易将所有系统混在一起设计。

以泊车业务为例，系统设计需平衡通过限位器时的体验与安全。从体验角度，希望车辆能流畅通过减速带等障碍，这需要较大扭矩；从安全角度，需避免车辆冲破限位器导致碰撞，这又对扭矩有一定限制。

传统设计思路中，开发工程师试图通过调整单一扭矩传感器的参数，同时兼顾通过性与安全性，还需考虑车辆载重等因素，最终陷入复杂的权衡困境。

而拆分设计思路则将系统分为安全系统和体验系统。安全系统专注于扭矩保护，不考虑体验，例如当扭矩超过设定值时触发保护机制，确保车辆不越过限位器，可采用独立的扭矩传感器；体验系统通过纯视觉判断库位和限位器位置，力求实现平稳停车，即便偶尔失效，安全系统也能发挥作用。

两个系统相互独立，无需在功能上相互妥协。安全系统被触发时产生的数据，能为体验系统的优化提供依据，助力其快速迭代。如此，即便体验系统初期不够完善，也能实现快速量产，经过3-6个月的迭代，体验系统可逐步成熟，减少安全系统的触发次数。

这种拆分思路与传统的权衡思路相比，能有效解决安全与体验的矛盾。在汽车行业与互联网行业的协作中，类似的矛盾普遍存在，如一方追求迭代速度，一方强调质量控制，若将两者置于同一维度权衡，只会陷入无休止的争论；而将其拆分为不同维度，则能化解冲突。

安全系统与体验系统的权衡在工程实现中至关重要。传统供应商在配置系统方面，主要关注CI集成的配置管理。在诊断系统中，传统的本地诊断会将故障ID号存储在寄存器中，而智能驾驶软件的诊断范围更广，包括用户行为记录、用户画像识别等。

影子模式是一种高效的测试方式，将下一版软件置于当前版本中，可检测系统可靠性，且借助用户车辆进行测试，相比传统的测试车队，具有量级大、成本低的优势。

需要注意的是，系统拆分并非简单地分为独立的体验系统和安全系统，而是呈现分层结构，每个层面都有其对应的安全与体验考量。

在设计系统时，功能系统和安全系统的感知输入最好保持独立，若受成本限制无法完全独立，也应遵循这一原则。例如，AEB理论上需要独立的感知输入。

控制链路必须由安全系统主导，这是系统设计的准则。在安全系统设计中，可靠通讯仅需应用于其输入和输出环节；安全系统向非安全系统发送指令时，无需保证可靠通讯，因安全系统可直接掐断非安全系统的控制链路。同时，需避免功能安全系统通过其他链路完成安全动作，防止出现逻辑混乱。

实际设计中易出现“多径问题”，即功能体验系统先于功能安全系统执行操作，影响安全系统的正常运作。例如，功能实现系统直接控制车辆停车，而安全系统尚未响应。为避免这种情况，安全系统触发时必须掐断所有上层信号，确保控制路径的唯一性。在信号传输设计上，应让信号先传递至安全系统，再由其转发至功能实现系统，保证安全系统对控制节奏的主导权，避免因CPU调度的竞争关系导致安全隐患。

三、系统各维度的解耦逻辑与发展阶段

在系统的各个维度，都存在类似互联网逻辑与汽车行业逻辑的划分，且两者需保持解耦。从EE架构到域控架构，再到车端软件级别和云端迭代，均是如此。例如，FOTA系统属于互联网逻辑范畴，而整车平台与EE架构的策略则属于汽车行业逻辑，二者相互独立。

在车端算法层面，互联网常用的网络模型与传统的规则算法也需解耦。以智能驾驶的路径规划为例，深度学习模型生成轨迹和速度变化后，规则算法会对其进行校验，如判断轨迹是否存在撞墙风险。若校验通过，则继续执行；若发现问题，安全系统会触发降级操作，并将相关信息反馈至云端。

深度学习与规则算法虽可能同源（如输入相同的地图信息），但二者的配合逻辑是为了校验深度学习结果的合理性。若输入源存在问题（如未识别到车道线），则属于上一级感知模块需解决的问题，而非该层级系统的校验重点。

在云端，训练平台虽在模型训练过程中相对灵活，可同时运行多个模型并根据测评结果选择最优者，但底层的控制逻辑仍需严谨。

总之，将安全系统与体验系统、互联网逻辑与汽车行业逻辑进行合理拆分与解耦，是系统设计的关键。这种思维方式在人工智能领域同样适用，如自动驾驶模型训练中，模型内部也需在可确定性与体验性之间进行权衡，这是所有智能体都需面对的问题，既要具备对外的适应性，又要保持自身的可控性。

接下来探讨三个层面的沟通问题。这部分内容较为复杂，因其涉及的范围广泛。相较于以往讲解EE架构时围绕区域架构等内容展开的简单模式，如今的架构讲解难度更大。在此，将以域控架构和集中化架构两个主要阶段进行阐述。

灵活性是系统设计的主线，追求极致的灵活性是永恒的目标，这一过程主要经历硬件集中化和软件无人化两个阶段。

分布式架构为保证高可控的质量，牺牲了一定的灵活性，将复杂性分担，使工程师有较大的操作空间，工作强度相对较低。

域控架构将部分子功能集中，并通过SOA（面向服务的架构）进行通讯衔接，此时系统复杂性开始呈现不均衡状态，工程师会感受到较大压力，工作时长相应增加。

集中化架构已接近工程师的能力极限。在该架构下，不同团队在中间件、操作系统、硬件等方面的选择易产生分歧，即便像特斯拉这样的企业，也会出现妥协方案。这种架构会导致组织架构层面的争夺，增加管理分层，延长代码集成时间，当仍采用规则算法时，系统复杂性会超出工程师的处理能力，许多尝试集中化架构的项目因难以推进而被迫拆分。

若组织架构和认知水平未达到相应程度，盲目采用集中化架构，是对质量的不负责任。在集中化架构的极限工况下，需在软件层面进行简化，主要通过自动化和模型化实现。自动化可利用CICTCD链路和大模型开发，控制软件迭代周期；模型化则可减少工程化负载。

端到端是更高阶段的发展方向，但需明确端到端只是体验系统的一部分，安全系统仍不可或缺。端到端的系统能实现车辆与自然环境的直接交互，减少人在车端的参与度，这也是智能驾驶的终局目标。对于集中化架构下的智能座舱和智能驾驶等大模型、大域控制器的融合，需综合考虑多方面因素。

四、架构设计的范围扩展与实践挑战

集中架构最本质的问题并非EE架构级别新增了一种结构理解方式，而是“控制器内设计和外设计变得更加模糊”，这增加了架构设计的难度。

控制器外的架构设计职责涵盖多个方面，包括服务框架、软件、系统、OTA（远程在线升级）、安全、诊断、网络、数据、电源、物理等架构相关内容，涉及功能定义、服务编排、软件协议栈需求、车云协同等多个维度。

控制器内的架构设计同样复杂，需考虑算法模型的选择（如归纳型神经网络算法与演绎型规则算法）、芯片类型（CPU、GPU、DSP、FPGA/ASIC等）的匹配、算力分配、通讯带宽与算力的平衡等问题。

以智能汽车的360功能为例，传统车辆中，360功能由座舱直接控制相机，启动较快；而在新型智能汽车中，相机常被智能驾驶系统使用，360功能的实现需经过座舱MCU、MPU，再通过SOA到智能驾驶系统等多个环节，链路较长，导致启动时间变长。

这一问题的背后涉及复杂的架构设计与组织架构。相机的启动时间、按钮反馈延迟等看似简单的问题，可能牵扯多家供应商和不同的组织架构，对工程师和管理者的全局思考能力提出了很高要求。在域控交互中，稳定性延时、启动时间等细节问题的解决，需要对汽车各个技术层面有协同思考的能力，准确识别问题根源，避免被局部利益所困扰。

总之，架构设计范围的极大扩展，使得智能汽车的系统设计面临诸多挑战，需要从全局出发，综合协调各方面因素，才能实现系统的高效运作与良好体验。