3. cubiX系统架构解析
cubiX 是采埃孚推出的车辆运动控制平台，其核心价值在于把原本分散在制动、转向、驱动、悬架等子系统中的运动控制能力，抽象为统一的软件平台，让整车厂和开发者能够以“车辆级”的视角去定义纵向、横向和垂向的运动行为。理解 cubiX 的架构，关键不是记住模块名称，而是看清各层之间的职责边界与接口约定：谁负责感知车辆状态，谁负责把驾驶意图翻译成各执行器能理解的指令，谁负责在多个执行器之间做协调与仲裁。
一、软件分层：从意图到执行的纵向切分
cubiX 的软件架构可以按“意图层—协调层—抽象层—执行层”来理解。最上层是驾驶意图与功能层，接收来自 ADAS 域控制器、人机交互或自动驾驶规划模块的目标请求，例如目标纵向加速度、目标横摆角速度、目标车身高度或阻尼模式。这一层不关心具体用哪个执行器实现，只表达“车辆应该呈现怎样的运动状态”。
中间是协调控制层，它是 cubiX 的“大脑”。协调层接收意图层的目标值，同时接收车辆状态估计层提供的当前车辆状态，经过动力学模型、约束检查和优先级仲裁后，输出各执行器可执行的协调指令。协调层的核心职责包括：多执行器能力分配、冲突消解、执行器动态补偿、失效降级策略以及舒适性与稳定性之间的权衡。
再往下是执行器抽象层，它把不同供应商、不同通信协议、不同物理特性的执行器统一成标准接口。抽象层向上提供“设置目标值、读取实际值、查询可用状态”等统一服务，向下则通过 CAN、FlexRay、以太网或私有协议与真实 ECU 通信。这样协调层不需要为每个执行器写一套专用逻辑，新增或替换执行器时只需更新抽象层的适配器。
最底层是执行器与车辆物理层，包括电子制动系统、电动助力转向、电驱动单元、主动悬架、后轮转向等。它们接收抽象层下发的目标值，完成物理动作，并把实际状态反馈回抽象层。
二、模块划分：职责边界与协作方式
在协调控制层内部，cubiX 通常划分为若干功能模块。纵向控制模块负责把目标加速度转化为驱动力矩和制动力矩的分配请求；横向控制模块负责把目标横摆角速度或目标路径曲率转化为前轮转角、后轮转角和横摆力矩请求；垂向控制模块负责阻尼力、空气弹簧压力或主动悬架作动力的分配。此外还有执行器管理模块，负责监控各执行器可用性、温度、故障码和性能降级状态。
这些模块之间不是简单的串行关系，而是通过共享的车辆状态和统一的协调周期并行运行。协调周期通常与整车控制周期对齐，例如 10 ms 或 20 ms。每个周期内，协调层先读取状态估计结果，再计算各模块的期望输出，最后通过仲裁器检查是否存在冲突。例如当纵向控制请求大驱动力、横向控制请求大横摆力矩时，若路面附着系数估计较低，仲裁器会同时削减两者，避免车辆失稳。
三、执行器抽象层：统一接口与能力描述
执行器抽象层的设计目标是“让协调层只面对能力，不面对硬件”。每个执行器在抽象层中注册一份能力描述，包括：可执行的控制量类型（力矩、角度、压力、阻尼力）、有效范围、最大变化率、响应延迟、通信周期、故障状态和降级模式。协调层根据这些能力描述做分配计算，而不是硬编码某个执行器的参数。
以电子制动系统为例，抽象层向上暴露的接口可能包括：setBrakeTorque(axle, torque_Nm)、getBrakeTorqueActual(axle)、getBrakeCapability()。抽象层内部则负责把标准接口转换为该制动 ECU 的 CAN 报文，例如把目标力矩拆分为左右轮请求，并处理报文周期、校验和与超时监控。当制动 ECU 报告温度过高时，抽象层把可用制动力矩上限下调，协调层在下一个周期自动感知并重新分配。
四、车辆状态估计与协调控制层的接口关系
车辆状态估计层是协调控制层的“眼睛”。它融合轮速、IMU、转向角、驱动扭矩、制动压力和摄像头/雷达信息，估计出纵向车速 v_x、侧向车速 v_y、质心侧偏角 β、横摆角速度 ω_z、纵向加速度 a_x 和侧向加速度 a_y。这些状态量通过标准接口以固定周期提供给协调层，并附带置信度或有效标志。
协调层对状态估计的依赖体现在三个方面：第一，目标值到执行器指令的转换需要当前状态作为反馈，例如横摆角速度闭环控制；第二，能力分配需要知道当前轮胎负荷和附着利用情况，避免某一执行器过载；第三，失效判断需要状态估计的置信度，当侧偏角估计置信度下降时，协调层应主动降低横向控制权限，进入更保守的稳定控制模式。
接口关系上，状态估计层与协调层之间通常采用共享内存或周期报文方式交换数据，周期与协调周期一致。状态估计层不直接控制执行器，协调层也不直接读取原始传感器，这种职责分离保证了估计逻辑和控制逻辑可以独立迭代。
五、一个协调周期的数据流示例
假设车辆以 80 km/h 行驶，ADAS 请求目标纵向加速度 1.5 m/s²、目标横摆角速度 0.08 rad/s。协调层在 10 ms 周期内执行以下过程：读取状态估计结果 v_x=22.2 m/s、β=0.5°、ω_z=0.06 rad/s；纵向模块计算需求驱动力矩约 420 N·m，横向模块计算需求前轮转角约 1.2°；仲裁器检查附着利用率约 0.35，未超限；抽象层把驱动力矩分配给前后电机，把转角请求发给电动转向；执行器在下一个周期反馈实际力矩 415 N·m、实际转角 1.18°；状态估计更新 ω_z=0.075 rad/s，协调层继续闭环修正。整个过程在 20 ms 内完成一次闭环，体现了 cubiX 从意图到执行再到状态反馈的完整链路。
理解 cubiX 架构的最终落脚点，是理解“分层解耦”带来的工程价值：意图层可以独立于执行器变化，协调层可以独立于硬件供应商变化，状态估计层可以独立于控制策略变化。每一层只通过明确定义的接口与相邻层交互，从而使车辆运动控制从“针对某个执行器写死逻辑”转变为“面向车辆运动能力做统一编排”。