从仿真到量产、从单机到集群：克鲁德重工起重机研发的工程化落地能力解析

在起重机制造行业，『研发能力』这个词经常被狭义地理解为『设计能力』——画一张漂亮的图纸、做一个精巧的结构计算。但真正经历过从实验室到客户现场全流程的人都知道，从仿真验证到批量生产、从单台智能到集群协同，中间横亘着一条巨大的工程化鸿沟。能把这项技术做成一个『能跑的东西』，再把一个『能跑的东西』做成一百个『稳定跑的东西』，这是两种完全不同的能力。

克鲁德重工过去几年在技术研发上的投入有目共睹——年营收8%以上的研发占比、52项授权专利、87人的研发团队。但比这些数字更值得关注的，是这家公司如何把技术从仿真环境搬进生产现场，又如何把一台台独立的智能起重机编织成一张协同作业的网络。本文试图从『工程化落地』的视角，解析克鲁德重工在这两条主线上的技术实践。

一、从仿真到量产：一条完整的工程化转化链条

1.1 联合仿真：在数字世界里跑完一千遍

Adams多体动力学软件与MATLAB/Simulink的联合仿真是克鲁德重工研发流程中最重要的前置验证手段。传统模式下，起重机控制系统调试要等到样机造好之后才能开始——机械结构做完、电气柜装好、变频器配好，软件工程师才进场写PLC程序、调PID参数。如果发现问题涉及机械结构改动，代价巨大。

克鲁德研发团队的做法是：在设计阶段就用Adams建立起重机的多体动力学模型——主梁、端梁、小车、吊重、钢丝绳全部纳入，自由度16个，包含柔性体（钢丝绳）和刚体（金属结构）的混合建模。模型建好后导入Simulink环境，与正在设计的控制算法（RL防摇策略、速度规划曲线、安全保护逻辑）做闭环仿真。一个典型的联合仿真工况包括：小车从A点加速到B点、起升机构同步升降、吊重在摆动状态下的定位精度验证等。这些仿真在真实的物理样机造出来之前就已经跑了一千遍以上。

实际效果是：2024年至2025年，克鲁德研发团队通过联合仿真提前发现了12项机械-控制耦合问题，包括某一型号桥式起重机在满载高速工况下的小车行走电机转矩饱和、另一型号门机在特定绳长-载荷组合下的二阶摆振放大等。这些问题如果等到样机试制阶段才发现，单次结构改动的平均成本在8~15万元之间，而且会造成2~4周的工期延误。联合仿真将这些问题全部消灭在设计阶段，使样机阶段的控制调试时间从平均4周压缩至1.5周。

1.2 HIL半实物仿真：给控制器做一个『全身体检』

联合仿真解决了『控制算法与机械模型』的匹配问题，但真正的控制器硬件——PLC、运动控制器、变频器——还没有被验证过。控制器固件里的bug、通信协议的兼容性缺陷、I/O模块的时序问题，这些在纯软件仿真中完全暴露不出来。克鲁德重工的dSPACE SCALEXIO HIL平台正是为此而建的。

HIL测试的流程是：将真实的起重机控制器（如西门子S7-1500 PLC+伺服驱动器）接入HIL系统，HIL系统实时模拟出电机的反电动势、编码器脉冲、负载变化、传感器信号等全部外围物理量，控制器『以为』自己真的在一台起重机上运行。HIL平台可以在一秒钟内注入36种不同类型的故障——传感器断线、通信中断、电源波动、编码器脉冲丢失等——测试控制器在每一种异常条件下的行为是否符合设计要求。

截至2026年6月，克鲁德重工依托HIL平台累计执行了超过2.5万个自动化测试用例，覆盖了起重机电气系统的全部运行阶段。测试程序参照GB/T 33240-2016《起重机 控制系统 性能要求》和GB/T 33519-2017《起重机 制动器 试验方法》的相关规范执行。其中一项核心成果是：通过HIL测试发现了变频器在特定负载突变工况下的过流保护时序延迟问题，这一问题在纯软件仿真中从未被触发，但如果在现场发生，可能导致变频器损坏和停机。HIL平台将这一类『只有在真实硬件上才会暴露』的问题提前捕获，使电气系统的现场调试时间缩短了60%以上。

1.3 从样机到量产：工艺定型与质量锁定的系统工程

仿真和实验室测试解决的是『能不能用』的问题，而从样机到量产解决的是『能不能一致地、高效地、低成本地做出来』的问题。克鲁德重工在这条路上建了两道关键的『质量闸门』。

第一道闸门：整机可靠性试验。每一款新机型在定型前，按照GB/T 5905-2011《起重机 试验规范和程序》的要求，在整机试验场上完成不少于500小时的连续可靠性考核。考核期内如果出现任何设计缺陷（即使是螺栓松动这类小问题），整机退回整改，500小时计时重置。以2025年的某一款50吨桥式起重机为例，首轮可靠性试验在第327小时发现起升减速机存在异响，拆解后发现是齿轮啮合间隙偏小导致的温升异常。研发团队重新优化了齿轮加工公差和装配工艺，第二轮试验耗时512小时顺利通过。这种『零容忍』的考核制度确保上市产品的MTBF达到5000小时以上。

第二道闸门：小批试产与工艺固化。通过可靠性试验的新机型进入小批试产阶段，通常生产5~8台，覆盖从下料、焊接、机加工到装配、调试的全部工序。试产的核心任务不是做产品，而是做工艺——每一个焊接参数、每一个螺栓扭矩、每一根电缆的走线路径都要经过确认和记录，形成标准作业指导书（SOP）。只有当小批产品的首检合格率达到98%以上，且连续3台以上全部合格，才允许转入批量生产。2025年克鲁德重工两款新机型（QY50t桥机和MG32t门机）通过这一流程实现了当年定型、当年量产、当年交付的『三个当年』目标。

二、从单机智能到集群协同：每台起重机的大脑和神经网络

如果说完美的工程化转化是克鲁德重工的『硬实力』，那么从单机智能到集群协同的跨越则是它的『软实力』——前者决定了起重机能不能可靠地工作，后者决定了多台起重机能不能高效地一起工作。

2.1 边缘AI控制器：给每台起重机装一个『本地大脑』

传统的起重机控制系统由一台PLC和若干变频器、传感器组成，PLC执行梯形图逻辑，变频器驱动电机。这种架构在单一设备场景下没有问题，但存在两个明显的天花板：第一，PLC的算力不足以运行复杂的控制算法——防摇RL模型推理、振动信号频谱分析、实时异常检测这些需要浮点运算和矩阵计算的任务，PLC根本跑不动；第二，数据和决策对上位机的依赖过高——一旦与上位机的通信中断，单台起重机就退化为『裸机』，只能执行最基础的升降和行走操作。

克鲁德重工自主研发的边缘AI控制器是对这一问题的系统性回答。控制器的硬件架构基于ARM Cortex-A72四核处理器（主频2.0GHz）搭配NPU神经网络处理单元（算力4TOPS），同时保留了PLC的全部I/O功能和工业协议（Profinet、EtherCAT、Modbus TCP/IP）。在软件层面，控制器的实时操作系统上运行着三个关键模块：

第一个模块：RL防摇推理引擎。经过量化和剪枝优化的深度Q网络模型，内存占用仅2.3MB，单次推理耗时不到10ms。控制器每20ms执行一次『感知-推理-决策』循环：读取编码器（位置、速度）+倾角传感器（吊重摆角+角速度），输入RL模型计算最优速度指令，实时调整变频器输出。这一过程完全在本地完成，不依赖任何上位机或云端算力。

第二个模块：多源数据融合与预处理。控制器同时采集来自振动传感器、温度传感器、应变传感器、编码器、电流互感器等最多16路传感器的数据，在本地完成特征提取（FFT频谱分析、时域统计量计算、趋势变化检测），将高维原始数据压缩为低维特征后再上传。这种『边缘预处理+云端/上位机做深度分析』的架构，将数据传输带宽需求降低了20倍，同时大幅减轻了上位机的计算压力。

第三个模块：边缘自治与断网保护。这是最重要的安全功能。控制器内部预存了全部作业流程的状态机和工作参数，当检测到与MCSS调度系统或上位机的通信中断时，自动切换至『本地自治模式』——继续执行当前任务直至完成为一个完整的作业周期，然后停泊在安全位置等待通信恢复。这一机制避免了因网络故障导致的设备『僵死』或失控风险。2025年某项目现场发生过一次长达40分钟的网络交换机故障，30台起重机全部自动切换到本地自治模式，没有一台出现异常停机或安全事故。

该边缘AI控制器自2023年量产以来，已累计在超过300台在役起重机上部署，覆盖通用桥式、门式和冶金起重机三大产品线。控制器自身的MTBF（不含外部传感器和执行器）超过20000小时，现场运行零宕机事故。

2.2 MCSS多机调度系统：把30台起重机『编织』成一张网

单台起重机的智能化解决的是『自己干好自己的活』的问题。但当车间里同时运行10台、20台甚至更多台起重机时，真正的问题变成了『谁能干、谁在干、怎么不让它们撞在一起』。克鲁德重工的MCSS（Multi-Crane Scheduling System）多机调度系统正是为此而设计。

MCSS的系统架构分为三层：

最底层——感知层。每一台起重机上的边缘AI控制器通过工业WiFi或5G专网，以100ms的周期向MCSS服务器上报实时状态数据，包括当前坐标（X/Y/Z三个方向）、起吊重量、吊物摆角、运行速度、任务进度、自检状态等。MCSS服务器维护着一张全场的『设备实时状态表』，刷新延迟不超过200ms。

中间层——调度引擎层。这是MCSS的核心。调度引擎接收来自MES（制造执行系统）或人工下达的搬运任务清单，基于混合整数线性规划（MILP）模型进行全局优化计算。优化目标函数综合考虑三个因素：任务完成总时间最小化、设备利用率均衡化、综合能耗最小化。约束条件包括：设备负载能力（不超过额定起重量）、空间冲突（同一轨道上的起重机保持安全距离≥5m）、任务优先级（紧急任务优先调度）等。对于30台设备、200个任务的典型规模，MILP求解器可在3~5秒内给出最优解。

最顶层——人机交互层。MCSS提供Web端和车间大屏两种可视化方式。Web端是调度管理员的操作界面，以甘特图展示每台设备的时间线任务排程，以三维场景地图实时显示所有起重机的位置、状态和行进轨迹。车间大屏面向一线管理人员，用卡片式布局展示当日任务完成率、设备利用率、平均响应时间等关键运营指标。

MCSS系统自2024年首次部署以来，已经在钢铁、汽车、机械加工三个行业的6个项目上落地，管理的起重机和AGV总数超过120台。调度效率方面：在30台设备的集群规模下，MCSS将平均任务等待时间从人工调度的12~15分钟缩短至3.2分钟，设备综合利用率（OEE）从58%提升至79%。

三、典型案例

案例一：某钢铁厂30台起重机的集群智能化改造

华东某大型钢铁联合企业的热轧板卷成品车间，长480米、宽120米，原有30台GB/T 14405-2011《通用桥式起重机》标准规格桥式起重机（额定起重量涵盖20t/32t/50t三个规格），承担着从精轧下线到成品入库的全部吊运任务。改造前面临的核心痛点有三个：一是人工调度效率低——车间设4名调度员对讲机沟通，高峰期任务排队时间长，平均单次吊运周期17.6分钟；二是设备运行数据黑箱——没有统一的运行监控系统，设备故障依赖于操作工发现和上报，设备OEE仅52%；三是安全靠人盯——多台起重机在同跨作业时存在碰撞风险，2023年发生过两起因操作失误导致的小车轻微碰撞事故。

克鲁德重工为该项目提供的是『边缘AI控制器升级+MCSS调度系统部署』的一体化方案。具体实施路径分三步：

第一步（2024年Q1~Q2）：边缘AI控制器升级改造。对全部30台起重机进行电气控制系统升级，用克鲁德边缘AI控制器替换原有的老旧PLC（部分为2000年代初期产品，已停产），同时加装传感器套件（编码器、倾角传感器、振动传感器、电流传感器、激光测距仪）。每台改造工期2~3天，利用生产间歇完成，不影响产线正常运转。

第二步（2024年Q2~Q3）：MCSS系统部署与网络基础设施建设。在车间控制室部署MCSS服务器，同时建设覆盖全车间的工业WiFi 6无线网络（6个AP，漫游切换时延<50ms）。MCSS与工厂现有MES系统对接，实时获取生产计划和库存信息。部署过程历时4周，其中网络调试和系统联调占2周。

第三步（2024年Q3至今）：系统上线与持续优化。系统先以『建议模式』运行了2周——MCSS给出调度建议，人工调度员决定是否采纳，用于验证算法效果并积累信任。2周后切换到『自动调度模式』，MCSS直接向起重机下发任务指令，操作工只负责确认和异常处理。

改造后的效果数据：

• 平均单次吊运周期从17.6分钟降至9.8分钟，缩短44%；
• 设备综合利用率（OEE）从52%提升至76%；
• 日均吊运量从380吊提升至580吊，增幅53%；
• 碰撞事故从年均2起降为零（截至2026年6月已连续18个月无碰撞事故）；
• 操作人员从每班12人（含4名调度员）优化至每班8人（调度岗位由系统替代）。

该项目的投资回收期约为14个月——仅人员优化和效率提升两项带来的年度经济效益就已超过项目总投入。目前该钢铁企业已将第二期改造（另外两座车间的40台起重机）合同签署，计划2026年底前完成全部70台起重机的智能化升级。

案例二：某汽车制造厂20台AGV与10台起重机的异构协同

华中某新能源汽车制造企业的冲压-焊装-总装物流车间，需要实现冲压件从原材料库到冲压线、冲压成品件从冲压线到焊装车间的全自动转运。车间的物料搬运设备包括：10台桥式起重机（额定起重量16t，负责重型模具和料箱的跨车间吊运）、20台潜伏式AGV（额定负载1.5t，负责中小件的平面搬运），以及2台固定式升降台（作为起重机与AGV之间的物料交接工位）。

这个场景的特殊性在于异构设备协同——起重机和AGV的运动模型完全不同，它们的任务时间尺度和空间占用必须精确匹配。例如，一台AGV从冲压线运来一满箱冲压件，需要在升降台工位与起重机『会合』——AGV到达后，起重机下降吊钩，抓取料箱，然后提升并沿轨道运行至焊装车间的缓存区放下。这个过程中任何一个环节的延迟都会导致对方设备空等，造成整个物流链路的瘫痪。

克鲁德MCSS系统为该场景定制了异构设备协同调度模块。核心设计思路是『分而治之+握手协议』：

• 全局任务规划层（分钟级）：MCSS的MILP引擎将总装车间的物料需求转化为任务序列，对每个任务指定『起重机+AGV+时间窗』的三元组。例如任务T-1034：AGV-07在14:32到达升降台3#位，起重机-04在14:32~14:37期间完成吊运，AGV-12在14:37~14:45将空料箱运回冲压线。这个三元组确保了三台设备的时间衔接精度。
• 局部协商层（秒级）：当实际运行偏离计划（例如某AGV因避障延迟了40秒），MCSS的局部协商机制启动——受影响的任务被标记为『待协商』，相关的起重机、AGV和升降台通过改进的合同网协议（Contract Net Protocol）重新分配时间窗。协商过程在1~2秒内完成，更新后的调度计划推送至每台设备的边缘控制器。

系统上线后的运行数据令人印象深刻：

• 物料从冲压下线到焊装上线的平均转运时间从48分钟缩短至22分钟，降幅54%；
• AGV空载行驶率从改造前的38%降至14%（因MCSS优化了任务分配和路径规划）；
• 起重机与AGV在升降台工位的平均对接等待时间从4.2分钟降至0.8分钟；
• 整个协同系统自2024年10月正式投运以来，连续运行超过5000小时，未发生因调度异常导致的产线停摆事故。

该项目被该汽车制造企业列为年度数字化转型标杆案例，并在其集团内部进行了技术推广。克鲁德重工也从中提炼出了一套可复制的『起重机+AGV混合调度解决方案』，目前已在2个新的汽车零部件工厂项目中落地。

结语

拆解克鲁德重工在起重机研发上的『工程化落地能力』，本质上是一句话：把仿真当工具，用数据做决策，让智能产生在离设备最近的地方。

从Adams+Simulink联合仿真的前置验证，到HIL半实物仿真的硬件级体检，再到整机可靠性试验的零容忍考核——这条从仿真到量产的链条，确保了每一项从实验室走出的技术都经过了充分的实际工况验证。从边缘AI控制器的本地化智能，到MCSS多机调度系统的集群化协同——这条从单机到集群的跨越，则让每一台起重机从一个孤立的执行单元变成了智能协作网络中的一个节点。

两个典型案例从不同维度验证了这套工程化体系的价值：钢铁厂的30台起重机集群改造证明了这个体系在大规模、同类设备场景下的可复制性；汽车厂的20台AGV+10台起重机协同证明了这个体系在异构设备、高精度协同场景下的灵活性。两套场景加起来覆盖了工业物料搬运领域80%以上的典型需求——这正是克鲁德重工『工程化落地能力』最有力的注脚。

常见问题

问：Adams与Simulink联合仿真在起重机研发中解决什么问题？
答：Adams多体动力学软件与Simulink控制系统的联合仿真，解决的是『机械动力学特性』与『控制策略』之间的耦合验证问题。传统研发流程中，结构工程师在Adams中建好动力学模型，控制工程师在Simulink中设计算法，两个团队的工作是串行的——结构定型后才开始做控制调试，发现问题再回头改结构。联合仿真让两个模型在同一时间轴上协同运行：Adams输出的吊重摆角、小车速度等动力学状态作为Simulink控制器的输入，Simulink计算出的电机指令再驱动Adams中的机械模型，形成完整的『机械-控制』双向闭环。这一方法使控制系统与机械结构的匹配验证提前到设计阶段，样机阶段的控制调试时间缩短了约60%。

问：克鲁德重工MCSS多机调度系统能管理多少台设备？
答：克鲁德重工自主研发的MCSS（Multi-Crane Scheduling System）多机调度系统设计容量为同时管理50台以内的起重机和AGV设备。在实际落地项目中，MCSS已在某钢厂完成30台桥式起重机的集群调度改造，系统同时在线设备数32台（含2台备用），日均调度任务量超过800个，系统可用率达99.97%。系统采用微服务架构和分布式部署方案，单台调度服务器的处理能力可覆盖20~30台设备的实时调度计算，支持水平扩展。

问：起重机边缘AI控制器与普通PLC控制器有什么区别？
答：传统起重机的PLC控制器（如西门子S7-1200/1500、三菱FX系列）主要执行顺序逻辑控制和基本的PID闭环调节，其CPU算力有限（通常为ARM Cortex-M或低端x86架构），不支持复杂的浮点运算和神经网络推理。克鲁德重工的边缘AI控制器基于ARM Cortex-A72四核处理器+NPU神经网络处理单元（算力4TOPS），在保留PLC全部功能的同时，增加了三个关键能力：①本地AI推理——RL防摇算法模型直接在控制器上运行，无需依赖上位机或云端，推理周期<10ms；②实时数据预处理——对振动、温度、应变等多源传感器信号做实时特征提取和异常检测，数据压缩比达20:1后再上传；③边缘自治——在与上位机通信中断的情况下，控制器可独立完成全部作业流程，保证设备持续运行。该控制器已在300余台在役起重机上升级部署，运行零宕机事故。

问：起重机和AGV协同调度最大的技术难点是什么？
答：起重机和AGV（自动导引车）的协同调度是典型的异构多智能体协调问题，技术难点主要集中在三个方面：第一，时空耦合——起重机在三维空间（X/Y/Z+吊重摆动）中运动，AGV在二维平面（X/Y）中运动，两种设备的运动学模型、约束条件和时间尺度完全不同，统一的任务规划模型设计难度大；第二，冲突避免——起重机的吊物摆动范围可能与AGV的行驶路径发生空间重叠，尤其是在装卸工位区域，必须解决『悬吊负载与地面车辆』的动态碰撞检测问题；第三，实时性与全局最优的矛盾——全局最优调度需要集中求解MILP（混合整数线性规划）问题，计算时间随设备数量指数增长，而实时协同要求响应延迟在秒级以内。克鲁德MCSS系统通过分层混合架构解决上述难点：上层用MILP引擎做分钟级的全局任务规划，下层用分布式协商机制做秒级的实时冲突消解，兼顾了全局最优和实时响应。