干城轨车辆控制的工程师对“牵引力控制”这四个字应该都不陌生。早些年我们讨论牵引控制基本都在讲单车的牵引计算、黏着利用、空转保护每个动力单元各自为战。但近几年随着列车通信网络和整车控制架构升级业内的思路已经明显在往“网络集中控制”这个方向上靠整车通过列车级网络统一采集各节车的载荷、速度、轮径、黏着状态再由中央控制单元协调各动力单元的牵引力输出。这个“集中协调”的思路解决的不只是舒适度问题更重要的是把整车牵引力用得更聪明——坡道起步不空转、雨天加速不打滑、故障后还能靠剩余动力单元撑到站。这篇博文就基于这个题目展开把网络集中控制框架下城轨列车牵引力控制的研究思路、核心算法、通信架构、仿真验证和工程落地中的坑完整梳理一遍。适合从事列控系统、牵引变流器控制、车载网络设计的工程师以及正在做相关课题的研究生参考。1. 研究方法与整体设计思路拆解1.1 从“单车闭环”到“整车协同”的控制逻辑转变理解这个研究先要清楚传统的城轨牵引控制是怎么做的。传统方案下每节动车各有自己的牵引控制单元司机控制器给出的牵引指令通过硬线或者低速总线广播到各车各车再根据自身载荷情况独立计算牵引力给定然后由牵引变流器执行。这种方式最大的问题是“信息孤岛”A车在打滑B车并不知道B车还在按照正常黏着条件猛出力结果是整列车牵引力利用率下降严重时还会加剧轮轨磨损。网络集中控制的核心变化是把原来分散在各车牵引控制单元里的“决策权”上收。列车级中央控制单元通常集成在列车控制与管理系统里通过贯穿全列车的实时网络周期采集每节动车的速度、加速度、载荷、电机的电流扭矩反馈、轮对转速、黏着利用程度等状态量然后在统一的整车控制周期内求解一个牵引力分配问题再把计算结果通过周期报文下发给各个牵引控制单元执行。这个过程听起来简单但真正做起来牵扯到网络实时性、控制周期同步、故障降级等一系列问题。1.2 集中控制方案要解决的关键需求我把这篇研究的核心需求拆成三点。第一点是牵引力的全局优化分配。城轨列车在运行中载荷是动态变化的早晚高峰挤满人平峰时段空得很而且前后节的乘客密度往往不均匀。传统单车控制只知道自己这节车的载荷没法照顾整车。集中控制则可以在整车层面做“按需分配”载荷重的车多出力载荷轻的车少出力同时保证总牵引力满足司机指令要求这样能显著降低能耗还能减轻轮轨的纵向冲荡。第二点是黏着利用的协同管理。轮轨间的黏着条件是瞬变的尤其是在雨天、落叶季、轨道面有油污的场景下。集中控制可以做到整车协同限力——某节车检测到黏着利用接近极限通过网络把该车的信息同步给中央控制单元中央单元在毫秒级时间内重新分配各车牵引力把受限车的负荷转移到还有黏着余量的车上。这个能力是单车闭环很难具备的。第三点是故障容错下的动力重分配。城轨列车运行中偶尔会遇到牵引变流器故障或电机切除的情况。传统做法是故障车退出动力其余车维持原控制策略整列车牵引力自然下降。集中控制能在故障发生后通过网络重新协调剩余动力单元的牵引力输出让可用动力单元尽量补齐牵引力缺口保证列车能维持运行到下一站而不是在区间内趴窝。2. 核心控制算法与关键技术细节2.1 牵引力分配策略的数学模型集中控制最核心的部分就是牵引力的实时分配算法。这个算法在本质上是一个带约束的优化问题但工程上通常不会直接做在线优化因为在线优化求解时间不可控容易超出列车控制周期。实际研究中用的是“规则计算 边界修正”的思路。设整列车需要的总牵引力为 F_total由司机控制器或ATO自动驾驶系统给定。共有 N 个动力单元通常是一个动车转向架算一个动力单元各动力单元实时载荷为 M_i当前黏着利用率为 η_iη 越高说明越接近打滑极限。基础分配原则是载荷比例分配F_i F_total × (M_i / ΣM_i)也就是载荷大的动力单元多出力。这个公式是基础骨架但真正实施时要加两个修正。第一个修正是黏着修正。如果某个动力单元的黏着利用率 η_i 超过预设阈值则将它的分配系数下调下调空出来的牵引力平均或按比例转移到其他黏着利用率较低的动力单元上。这个修正本质上是给基础分配公式加了一个与黏着状态相关的权重因子。第二个修正是动态限制修正。每个动力单元的牵引力都要受到两个边界的约束一是牵引变流器的最大输出电流边界二是黏着边界即当前轮轨条件下能施加的最大牵引力。分配结果必须同时满足这两个边界这就要在每次控制周期内做一次带边界的分配计算。2.2 基于蠕滑速度的黏着利用控制要讲牵引力控制绕不开黏着和蠕滑这两个基本概念。简单来说轮轨之间能传递的牵引力受黏着系数限制而黏着系数不是固定值它随蠕滑速度变化。蠕滑速度就是轮对线速度与列车运行速度的差值——轮子在牵引时总要“稍稍快于”车体运行速度这个相对滑差就是蠕滑。实验曲线告诉我们黏着系数随蠕滑速度的增大先升高后降低存在一个峰值点。控制的目标就是让蠕滑速度维持在峰值点附近从而获得最大黏着利用。网络集中控制在这个问题上有一个天然优势蠕滑速度的计算需要同时知道轮对线速度轮速传感器精确测量和列车运行速度需要参考速度而参考速度的估计在单车控制下容易受到本车打滑轮对的影响集中控制却可以综合全列车的轮速信息剔除异常轮对得到更准确的列车参考速度。我见过实际工程中的做法是中央控制单元收集所有动车的轮速信号先做一致性判别剔除明显偏大的轮速打滑轮和明显偏小的轮速滑行轮对有效轮速取加权平均作为参考速度送到各动力单元的黏着控制器里。这样参考速度更稳蠕滑速度计算误差明显减小。2.3 空转/滑行保护与再黏着恢复空转和滑行是牵引控制里必须处理的现象。空转发生在牵引工况下轮对转速急剧上升轮轨黏着丧失滑行发生在制动工况下轮对被抱死或转速急剧下降。网络集中控制下的空转保护跟单车控制最大的不同在于“检测”和“恢复”两个环节。在检测环节集中控制不只依赖单车的轮加速度信号还会参考整车层面的一致性判断。举个例子某节车报轮对加速度异常但同一时刻其他车都正常列车参考速度也没有突变中央控制单元可以快速判定该车发生空转并通过网络下发指令降低该车牵引力给定值。响应时间取决于网络周期通常可以做到几十毫秒到一百毫秒以内比传统的硬线空转继电器方案快得多。在恢复环节集中控制的优势更明显。单车控制下空转车的牵引力降低后要等轮速回落并重新建立黏着才能加力这个过程中整列车牵引力是缺失的。集中控制则可以在空转车减载的同时让其他动力单元按比例补偿牵引力保证列车总牵引力基本不跌。等空转车轮速恢复正常再逐步收回补偿量。这样一来乘客几乎感觉不到车辆动力的突然中断舒适度和运行效率都上去了。3. 网络集中控制通信架构与实时性设计3.1 车载网络选型与拓扑结构集中控制的前提取决于网络能不能在严格的时间内把状态量汇聚上来、把控制量发下去。城轨列车上常见的网络有两种一种是符合IEC 61375标准的TCN列车通信网络绞线式列车总线加多功能车辆总线另一种是近年来用得越来越多的工业实时以太网方案包括基于TTE时间触发以太网或者基于TSN时间敏感网络的列车网络。从研究角度来说TCN架构资料多、技术成熟很多论文和工程验证都基于它来做。实际项目中中央控制单元挂在列车总线上各车的牵引控制单元通过车辆总线接入网络拓扑大体是“列车级总线骨干 车辆级总线接入”的两级结构。在做网络集中控制的研究时重点关注的是两级网络的数据交互时延和周期同步能力。3.2 周期报文设计与硬实时约束牵引力控制对实时性的要求是硬约束。整车控制周期通常取10ms到20ms也就是说中央控制单元每10ms或20ms要完成一次状态采集、分配计算、指令下发。在这个周期内网络传输必须完成以下几步各动力单元的牵引系统状态轮速、扭矩反馈、黏着状态、故障标志汇聚到中央控制单元中央控制单元完成牵引力分配计算分配结果下发到各动力单元的牵引控制单元。这意味着网络报文时延必须远小于控制周期。一般情况下端到端时延控制在5ms以内抖动控制在1ms以内才能保证控制品质。TCN在这种场景下设计周期报文时要合理划分周期相位的提前量确保数据采集早于控制计算开始时刻。TTE或者TSN的方案则在硬件层面通过时间同步来保障各节点在同一时刻采样这对牵引力分配的一致性非常有帮助。3.3 时钟同步与事件优先级管理集中控制里还有一个容易被忽视的细节各动力单元的采样时钟必须对齐。如果A车在t时刻采样、B车在t4ms采样那么中央控制单元拿到的整车状态在时间上就是错位的基于这个状态做出来的牵引力分配结果自然会有偏差。所以网络集中控制的实现中必须引入时间同步机制。IEEE 1588精确时间协议是工业以太网方案里最常见的同步方式同步精度可以做到亚微秒级完全满足需求。在报文优先级设计上牵引力控制相关的周期报文通常设置为最高的周期优先级故障信号和紧急指令使用事件型高优先级报文争取在1ms内抢占传输。像参数配置、故障记录、维护诊断这类非实时数据则放到优先级最低的发布/订阅通道里避免干扰实时控制报文的传输。4. 整车主环模型的搭建与关键参数选型4.1 列车纵向动力学模型要做网络集中控制的仿真验证第一步就是搭建整车的纵向动力学模型。列车模型的经典形式是M_total × a F_traction - F_resistance - F_grade其中 M_total 是整车等效质量a 是列车加速度F_traction 是各动力单元牵引力之和F_resistance 是基本运行阻力包含滚动阻力、空气阻力等F_grade 是坡道附加阻力。等效质量要考虑旋转部件惯量通常取车体质量的1.05到1.10倍。城轨列车编组常取6辆或8辆编组动拖比有4动2拖、6动2拖等多种形式。在仿真模型里我习惯把每个动力单元单独建模而不是图省事把整车简化成单质点模型。因为网络集中控制研究的就是各动力单元的差异和协同如果整车简化成一个质点那集中控制的优势就完全体现不出来了。每个动力单元单独建模之后各车载荷可以独立设置黏着条件也可以分车设置这样才好在仿真里复现“A车黏着差、B车黏着正常”这种真实场景。4.2 牵引特性曲线与黏着条件的参数设定牵引特性曲线的设定要贴近实际城轨列车的牵引特性。电机的牵引力输出通常分几个区段恒转矩区低速段、恒功率区中速段、自然特性区高速段。比如一个典型的城轨牵引特性可以这样设定0到40km/h恒转矩区牵引力近似恒定由电机最大转矩限制决定40到70km/h恒功率区牵引力随速度升高而降低70km/h以上自然特性区牵引力进一步下降。黏着模型的设定则要分正常和恶劣两种情况。正常情况黏着系数取0.16到0.18干燥轨面恶劣情况降为0.08到0.10模拟雨天或落叶轨面。在仿真对比实验里典型做法是让列车从静止开始加速前半段走干燥轨面运行到某一点后切换为低黏着条件观察集中控制策略下牵引力分配的变化和整车加速度的稳定程度。4.3 仿真对比工况的设计与结果解读仿真验证环节至少要做三组对比第一组是“正常轨面下的整车加速”验证基础分配算法在正常情况下能正常工作总牵引力满足指令各动力单元按载荷比例合理分担动力。第二组是“局部低黏着轨面下的协同控制”设定某几个动力单元进入低黏着区其他动力单元处于正常轨面对比网络集中控制策略和传统单车控制策略观察整车的加速度跌落情况、各单元牵引力调整过程、空转车轮速恢复速度。集中控制的预期结果是加速度跌落明显小于单车控制受限单元快速减载非受限单元快速补偿整车运行更平稳。第三组是“动力单元故障切除后的重分配”在运行中模拟某个动力单元因变流器过温被切除观察剩余动力单元能否通过牵引力重分配补回部分牵引力。预期结果是牵引力缺口由其他单元按比例分担整车动力损失比传统方式小能够维持基本运行速度。实施过程中一个容易踩的坑是模型里的载荷分布要设置成动态变化的不能所有车厢恒定为AW3载荷满载工况。实际线路的客流分布是不均匀的前四节和后四节的乘客密度差异很常见仿真如果不做动态载荷分布就验证不出集中控制“按载荷比例分配牵引力”的核心优势。5. 网络集中控制架构的核心设计——牵引力分配与网络协同5.1 整车牵引力集中分配模块的实现在工程实现上中央控制单元的软件里通常会做一个“牵引力管理”功能模块。这个模块的输入是司机指令或ATO指令的总牵引力需求以及从网络上汇聚上来的各动力单元状态信息输出是每个动力单元的牵引力给定值。分配计算的具体逻辑可以细分为三步。第一步是基础分配按载荷比例把总牵引力分配到各动力单元。第二步是黏着修正检查各动力单元的黏着利用率对超过阈值的动力单元下调分配系数同时对非受限单元做补偿性上调。第三步是边界约束对每个动力单元的分配结果做限幅确保不超过变流器最大输出能力也不超过黏着边界。每一步的计算量都不大在10ms控制周期内完成绰绰有余。5.2 网络指令传输的延迟补偿机制网络传输不是即时的中央控制单元下发的牵引力指令需要经过网络传输才能到达各动力单元的牵引控制单元。这个传输时延在TCN网络中通常是几毫秒在实时以太网中可以压缩到亚毫秒。时延本身不是大问题只要时延是确定的、可预知的控制算法可以通过在前一拍预测当前拍的状态来补偿。但时延抖动处理不好就很麻烦——如果每一拍指令到达的时间忽早忽晚牵引控制单元执行指令的时刻就对不齐整车牵引力的同步性就无从谈起。工程上的处理手法是牵引控制单元在接收到中央下发的指令后不立即执行而是打上统一的执行时标在指定的控制周期边界统一执行。这样即使报文到达时间有小幅抖动实际执行时刻依然是同步的。这个“执行时标”机制是我在工程现场调试时觉得最有效的做法。5.3 故障降级与协同控制策略网络集中控制最怕的就是网络本身出问题。一旦网络中断或者中央控制单元故障整车牵引控制不能瘫痪必须有降级策略。常见的降级方案是各动力单元在一段时间内收不到中央控制单元的有效指令后自动切换到本地独立控制模式按照本车载荷和本车黏着状态独立运行。这本质上回到了传统的单车控制模式。降级切换的关键点在于“无缝”。切换时要保证牵引力不发生突变否则列车会产生明显冲击。通常的做法是做斜坡切换在若干个控制周期内把中央分配的结果和本地计算的结果按比例混合逐渐过渡到纯本地控制。我在实际项目中做过类似的降级逻辑切换时间控制在200到500ms列车上几乎感觉不到异常。6. 常见问题与排查技巧实录6.1 网络抖动导致牵引力波动的排查思路我在仿真和半实物验证阶段遇到最多的问题就是网络抖动引起的牵引力波动。典型表现是各动力单元的牵引力给定值在正常运行中会出现高频小幅度抖动整车加速度曲线不平滑。排查思路分三步走。第一步先查网络报文刷新的实际周期看是否存在丢包或者延迟抖动第二步查时间同步状态确认各节点采样时刻是否对齐第三步查控制算法里的分配系数是否存在高频振荡的可能——比如载荷信号里有高频噪声分配计算直接用了原始值没做滤波就会把噪声放大成牵引力波动。解决办法是在每个动力单元的载荷信号进入分配算法前加一阶低通滤波滤波时间常数据经验通常取0.2到0.5秒。6.2 低黏着工况误判的调整技巧低黏着工况下集中控制偶尔会出现误判某个动力单元明明还有黏着余量却被判定为黏着受限导致牵引力被不必要地降低。这种误判通常是因为黏着利用率的计算依赖轮轨状态估计而低黏着条件下的轮轨状态估计本身误差就大。调整技巧是给黏着利用率阈值加一个迟滞区间。进入受限状态的阈值设低一点比如0.88退出受限状态的阈值设高一点比如0.75。这样就避免了系统在阈值附近反复切换既不会漏判真正的打滑风险也不会因为轻微扰动就误降牵引力。6.3 中央控制单元切换时的数据一致性采用冗余中央控制单元时主备切换会带来一个隐蔽问题备单元在切换前如果状态不同步切换瞬间会给各动力单元下发一个“陌生”的牵引力分配结果导致牵引力跳变。解决办法是让主备单元始终保持状态同步主单元每个控制周期把内部关键状态分配系数、修正量、降级标志实时同步给备单元备单元持续跟踪主单元的计算结果。这样切换发生时备单元的输出和控制状态都是连续的牵引力不会出现跳变。这块我建议在工程验证时专门做一次主备切换测试把切换瞬间的牵引力响应曲线拿出来看确认没有突变再放行。7. 仿真验证结果分析与经验总结7.1 正常轨面下的集中分配效果正常轨面黏着系数0.16到0.18工况下网络集中控制策略下各动力单元的牵引力与载荷比例分配理想值的误差可以控制在3%以内。整车加速度响应平稳总牵引力严格跟随指令没有出现振荡或超调。这种情况下集中控制和传统单车控制的差异反而不大——毕竟正常轨面下每节车都能充分发力集中控制的优势更多体现在异常工况。7.2 局部低黏着工况下的协同优势在局部低黏着工况下集中控制的优势非常明显。传统单车控制下低黏着动力单元因空转保护频繁减载整车牵引力出现周期性跌落平均加速度下降明显。网络集中控制下受限动力单元减载的同时其他单元迅速补偿整车牵引力基本保持平稳。实测仿真数据里整车平均加速度可以比单车控制策略提高8%到12%。更重要的是空转轮的恢复时间大幅缩短——这得益于参考速度估计更准蠕滑速度计算更稳定。7.3 故障切除工况下的重分配表现动力单元故障切除工况下集中控制的重分配策略能在200毫秒内完成剩余动力单元的牵引力补偿调整整车牵引力跌落幅度可以控制在20%以内。相比传统单车控制下牵引力直接损失一个动力单元的份额集中控制策略的实际表现要平稳得多。从整个实践过程来看网络集中控制的牵引力控制方法已经很成熟从算法设计到工程实现都有清晰的路径。但有一点我必须强调这个方法对网络质量的要求极高如果网络实时性不过关集中控制带来的性能优势会全部被通信时延吃掉。所以做这个方向的研究或者工程落地一定要把网络设计和控制算法放在同等重要的位置先保证网络硬实时再做上层算法。我个人在实际操作中最大的体会是不要贪图算法复杂稳定可靠的简单算法远比花哨却脆弱的复杂算法有价值。网络集中控制的核心竞争力在于“全局信息带来了更好的协调能力”把这个协调用好就已经足够解决城轨牵引控制里的大部分实际问题了。后续如果条件允许还可以把这个思路往制动控制、能耗管理方向扩展——同一套网络集中的框架解决的不应该只是牵引一个问题。