一、先分清你在选哪一层接口
运动平台开放接口，是客户上位机、仿真软件、试验系统或浏览器工具向平台下发位姿、轨迹、动作命令，并读取状态数据的应用层通信方式。采购和集成阶段真正需要确认的是 TCP、UDP、WebSocket、HTTP 这类客户接入接口，而不是 EtherCAT、CANopen、Modbus 这类内部现场总线。
运动平台接口选型的第一步，不是比较协议名字，而是分清“客户系统怎么接入平台”和“控制器怎么驱动伺服”这两层。
客户接入接口解决的是“我的系统怎么和平台说话”。它影响上位机软件开发、仿真系统联调、现场调试方式、数据记录方式，也影响验收时怎么复现一段动作或一组试验脚本。
内部现场总线解决的是“控制器怎么把指令送到执行器”。它处在运动平台内部，用于控制器、伺服驱动、IO 模块之间的实时通信。客户通常不直接编写这层代码，也不需要把这层当成软件集成入口。
如果一个项目已经指定了 Unity、ROS、LabVIEW、Matlab、PLC、MES 或客户自研上位机，接口讨论应先从客户系统出发：它能稳定发什么数据、希望按什么节拍交互、异常时由谁接管、调试和验收怎么记录。把这些问题确认清楚，TCP / UDP / WebSocket / HTTP 才有明确的选择依据。
二、运动平台的两层协议
六自由度运动平台不是由客户系统直接驱动 6 支电缸。更合理的工程边界是：客户系统把目标位姿、动作命令或试验脚本发给运动控制器；控制器负责轨迹处理、限位保护、伺服同步和状态反馈；内部总线再把实时指令分发到驱动器与执行器。
这也是开放接口和内部总线容易混淆的原因：它们都叫“通信协议”，但承担的任务不同，出现在交付链路里的位置也不同。
| 层级 | 主要任务 | 典型协议 | 交付边界 |
|---|---|---|---|
| 第 1 层 · 客户接入层 | 接收位姿、动作、脚本和控制命令，返回平台状态、报警和运行数据 | TCP / UDP / WebSocket / HTTP | 需要在接口文档中确认 |
| 第 2 层 · 内部伺服层 | 控制器与伺服驱动、IO 模块、执行器之间的实时通信 | EtherCAT / CANopen / Modbus 等现场总线 | 属于整机控制系统内部配置 |
客户真正需要确认的是第 1 层：数据格式、坐标约定、发送节拍、心跳机制、状态码、异常接管和验收脚本。第 2 层只有在项目涉及电控柜集成、指定伺服品牌、客户自有控制系统或特殊现场改造时才会进入讨论；即便讨论，它也是整机交付边界的一部分，不是常规的软件开放接口。
三、客户接入层怎么选
客户接入层的选择，先看你的系统怎么和平台交互。它不是单纯比较“哪个协议更高级”，而是确认数据节奏、可靠性要求、调试方式和现场集成对象。
| 接入方式 | 适合的交互方式 | 选它时要确认什么 | 典型项目 |
|---|---|---|---|
| UDP | 连续发送位姿、速度、姿态或轨迹点，下一帧可以覆盖上一帧 | 发送节拍、坐标系、丢包处理、心跳超时、异常停车策略 | 仿真训练、VR 体感、HIL、实时姿态复现 |
| TCP | 命令和状态一问一答，要求消息可靠送达 | 命令格式、响应码、重连策略、超时处理、文件或脚本传输方式 | 上位机控制、试验脚本、配置下发、日志读取 |
| WebSocket | 浏览器或 Web 工具需要持续双向通信 | 浏览器端权限、连接保持、状态推送、多人调试时的控制权 | Web 调试台、教学实验界面、现场演示工具 |
| HTTP | 企业系统、脚本或第三方平台按请求调用设备能力 | API 路由、鉴权、请求频率、任务状态查询、与 MES / SCADA 的字段映射 | 自动化脚本、设备管理、试验任务登记、数据归档 |
接口选择的关键不是“平台支持哪个协议”，而是“客户系统按什么节奏发数据、异常时谁接管、验收时怎样复现同一组动作”。
如果项目是连续运动复现，通常先讨论 UDP，因为它更适合高频位姿流；如果项目是试验脚本、动作命令和状态查询，TCP 或 HTTP 更容易做成可记录、可重放的流程；如果现场需要浏览器调试，WebSocket 比传统桌面工具更方便接入。
复杂项目经常组合多种接口。例如仿真主机用 UDP 推送实时位姿，WebSocket 做现场调试界面，HTTP 提供任务管理和数据归档，TCP 用于命令确认或配置下发。组合接口本身不是问题，关键是每条链路的职责要分清，避免多个系统同时争夺平台控制权。
选型时可以按 5 个问题收敛：
- 数据是连续位姿流，还是离散命令？
- 丢一帧是否可以被下一帧覆盖，还是必须可靠到达？
- 控制权在客户上位机、平台控制器，还是第三方系统？
- 异常断线、急停、超限和恢复流程由谁处理？
- 验收时是否需要保存脚本、日志和状态码用于复现？
四、内部现场通信解决什么问题
EtherCAT、CANopen、Modbus 经常一起出现在询盘或招标文件里，但它们解决的是设备内部通信问题，不是客户上位机的常规接入入口。它们的差异主要体现在实时性、设备模型、生态兼容和调试维护方式上。
| 现场通信 | 更常解决的问题 | 在运动平台里的典型位置 | 客户是否需要直接接入 |
|---|---|---|---|
| EtherCAT | 多轴伺服同步、驱动器链路、运动控制实时通信 | 控制器到伺服驱动器之间 | 通常不需要 |
| CANopen | 驱动器、传感器、嵌入式设备之间的对象化通信 | 小型设备网络、局部控制单元 | 只在特殊集成时讨论 |
| Modbus | PLC、仪表、IO、辅助设备的通用工业通信 | 辅助 IO、状态采集、外围设备对接 | 可能用于外部系统状态读取，但不等于运动主控接口 |
EtherCAT 的特点是把以太网用于现场级实时控制，常被用于多轴运动控制和分布式 IO。CANopen 强调设备对象、通信对象和网络管理，适合把驱动器、传感器、执行部件抽象成可配置的设备节点。Modbus 的优势是简单和通用，在 PLC、仪表、IO 模块和上位监控系统中很常见。
EtherCAT、CANopen、Modbus 值得在电控方案里认真选，但它们不应替代客户接入层的接口讨论。
对六自由度运动平台来说，客户真正关心的是平台能否接收目标位姿、按约定返回状态、在异常时进入明确的安全流程。内部用哪种现场通信，应服务于整机实时性、稳定性和可维护性，而不是把复杂度转嫁给客户上位机。
五、为什么不建议客户直接处理内部总线
让客户系统直接处理内部现场总线，看起来像是“更开放”，实际会把整机控制责任拆散。六自由度平台不是 6 个电缸的简单集合，控制器需要把空间位姿转换为各支链动作，同时处理限位、速度约束、同步、急停、回零、报警和状态恢复。
如果客户上位机绕过平台控制器，直接给驱动器或执行器下发底层指令，项目会遇到三类风险：
| 风险 | 具体表现 | 更合理的边界 |
|---|---|---|
| 运动学边界不清 | 单个执行器动作正常，但组合位姿可能超出机构、夹具或线缆边界 | 平台控制器统一处理位姿、限位和互锁 |
| 安全责任分散 | 急停、断线、超限、回零和报警恢复由多个系统分别处理 | 整机控制系统定义统一的异常流程 |
| 联调成本上升 | 客户既要写业务系统，又要理解伺服、总线和控制时序 | 客户接应用层接口，厂商封装实时控制链路 |
运动平台的开放接口应开放在“整机语义”这一层：目标位姿、动作模式、脚本任务、运行状态、报警信息、控制权切换。底层伺服链路则由整机控制系统负责，才能保证同一组动作在不同现场、不同负载和不同联调阶段有一致的控制边界。
某些项目确实会讨论内部总线，例如客户已有 PLC / 运动控制器、需要接入自有电控柜，或项目要求指定驱动器生态。这时讨论重点也不应是“把总线交给客户直接写”，而是明确谁负责运动控制、谁负责安全链路、谁负责验收脚本和接口文档版本。
六、项目接口确认清单
接口确认不应只停留在“支持 UDP / TCP 吗”。进入方案阶段时，建议把接口需求拆成可验收的问题，写进技术协议或接口文档。
| 确认项 | 需要写清楚的内容 |
|---|---|
| 控制对象 | 是控制平台整机位姿、单轴动作、预设动作，还是试验任务 |
| 数据内容 | 坐标系、单位、姿态角定义、速度或加速度字段、状态字段 |
| 数据节奏 | 连续推流、命令响应、任务触发、状态轮询或事件推送 |
| 控制权 | 客户上位机、平台控制器、浏览器工具、PLC 或第三方系统谁拥有控制权 |
| 异常处理 | 心跳超时、断线、急停、超限、报警恢复、回零流程 |
| 验收方式 | 脚本复现、日志记录、状态码、联调记录和接口文档版本 |
一个可交付的开放接口，不只是“能连上”，还要能被调试、能被复现、能在异常时明确接管。
在模拟训练项目里，重点通常是实时位姿流、视景同步、座舱安全和控制权切换；在测试验证项目里，重点通常是试验脚本、数据记录、重复执行和状态追溯；在企业系统集成里，重点可能转向任务管理、权限、数据归档和设备状态查询。
因此，接口选型最好不要孤立讨论协议名。先把应用场景、控制对象、数据节奏和验收方式定下来，再选择 UDP、TCP、WebSocket、HTTP 的组合，才是更稳的工程路径。
七、常见误区
误区一：招标写 EtherCAT 就说明接口更专业。
EtherCAT 可以是优秀的内部现场通信选择，但它不直接回答客户系统怎么接入平台。招标文件如果只写内部总线，却没有写清楚开放接口、控制语义和验收脚本，后期联调仍然会卡在上位机集成上。
误区二：UDP 不可靠，所以不能用于运动平台。
UDP 本身不保证送达，但连续位姿流的特点是“下一帧覆盖上一帧”。在仿真、VR、实时姿态复现这类场景里，低开销和连续更新往往比每一帧都可靠送达更重要。真正要确认的是心跳、超时、异常接管和平台安全策略。
误区三：HTTP 简单，所以可以承担所有控制。
HTTP 很适合任务创建、状态查询、数据归档和企业系统对接，但不适合把每一帧实时运动都做成请求响应。连续运动控制更适合用 UDP、TCP 或 WebSocket 承载，HTTP 则适合做管理层接口。
误区四：开放接口越底层越好。
对整机运动平台来说，开放到位姿、任务、状态和报警这一级更有价值。客户不需要重新实现运动学、安全互锁和伺服同步；这些底层能力由平台控制系统封装，才符合整机交付的责任边界。
参考资料
- IETF, RFC 768: User Datagram Protocol, 1980, https://www.rfc-editor.org/rfc/rfc768
- IETF, RFC 9293: Transmission Control Protocol, 2022, https://www.rfc-editor.org/rfc/rfc9293
- MDN Web Docs, Overview of HTTP, https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Overview
- WHATWG, WebSockets Standard, https://websockets.spec.whatwg.org/
- Beckhoff, EtherCAT, https://www.beckhoff.com/en-us/products/i-o/ethercat/
- CAN in Automation, CANopen knowledge, https://www.can-cia.org/can-knowledge/canopen
- Modbus Organization, Modbus specifications, https://www.modbus.org/modbus-specifications
延伸阅读
- 先理解平台原理：六自由度运动平台原理详解
- 继续看 UDP 接口设计：六自由度平台 UDP 通信接口设计
- 了解产品化接口：开放通信协议
- 评估二次开发边界：SDK 与二次开发