简介openTCS 5.9中文版用户手册是一份面向AGV调度系统开发者、实施工程师和物流自动化运维人员的中文技术文档。资源基于Apache License 2.0的开源运输管理系统openTCS详细解说如何通过控制台、运输任务管理器与车辆控制器完成车辆调度与任务分发帮助读者理解工厂建模中的点、路径、位置、车辆、块、图层等核心概念。压缩包仅含1个PDF文件大小约13.31MB便于阅读与检索已有595人学习下载。手册内容覆盖系统要求、许可与支持机制、系统概述及操作指南并整理了常见问题与解决方案既适合初次接触openTCS的入门者建立整体认知也能为已有实施经验的用户提供配置与排错参考从而提升AGV调度与物流作业效率。1. 开箱不是即用openTCS 是 AGV 调度框架不是“下载即控车”的成品openTCS 是一套开源 AGV 调度系统在同类 RCS 系统Robot Control System里它最大的特点是强调“通用框架”而不是“成品软件”。我最初接手某个跨平台系统的调度改造时也以为是装完就能看到小车间地图上车跑来跑去结果第一次启动才发现它没有车辆驱动、没有默认地图甚至连“车”的概念都需要你通过工厂模型去定义。它的价值在于把车辆路由、订单分配、车队交通管理这些 AGV 调度系统的核心底层逻辑先实现好让你不用从零造轮子但你必须为它补上通信适配器、模型和策略。这份 5.9 中文版用户手册就是补这些“落地”动作的最佳索引。适合正在选型或已经决定用 openTCS 控制 AGV 车队的从业者也适合想把调度系统摸透的开发者。2. 读透系统结构与工厂模型五大进程、四类要素和它们的边界2.1 内核与三类客户端谁负责“脑子”谁负责“手脚”openTCS 的系统结构比一般的单体软件要复杂一层。它采用客户端-服务器架构所有核心逻辑集中在内核Kernel这个独立进程中。内核负责三件事维护工厂的抽象行驶模型、管理运输订单、为车辆规划路线。这三件事里“抽象行驶模型”最容易被新手忽略——它不是你在编辑器里画的五颜六色的地图而是由点、路径、位置、车辆组成的纯逻辑拓扑车辆在地图上跑实际是在这个拓扑上做状态迁移。客户端则有三个标准角色。模型编辑器用来“画地图”也就是建工厂模型操作台用来“看现场”可视化工厂运行状态并交互式地下发运输订单内核控制中心常简称 KCC则是内核的“检修仪表盘”它负责把车辆驱动通信适配器挂载到具体车辆上并能查看底层通信报文。三者都是独立进程可以分散在不同的机器上运行手册第六章专门讲了跨机器部署的注意事项这为现场部署提供了很大灵活性但也意味着你调试时要多考虑一层网络连通性问题。如果要用 Java 以外的系统对接openTCS 内核还提供 RMI 接口和一套 Web API后者可以便捷地创建和撤销运输订单、订阅订单状态更新。常见的做法是仓库管理系统通过 Web API 把任务单推送给 openTCS而不是人坐在操作台前手工点按钮。这也是为什么我说它是“框架”而非“成品”——它把主骨架给你接缝处留给你去对接。2.2 点、路径、位置、车辆一张表拆完建模要素工厂模型是 openTCS 的灵魂但它的要素其实非常克制核心就四类再加上块、图层等辅助要素。我建议你在建模前先用下面这张表把概念对齐否则后面很容易把“点”和“位置”混为一谈。要素核心属性典型误区点类型停靠位置/报告位置/停车位置、坐标、车辆方向角把报告位置当成可停靠的目的地导致无法路由路径长度、最大行进速度、最大倒车速度、锁定标志、外设操作序列忽略长度和速度参数路由成本算不准位置类型、链接点集合、锁定标志、外设映射位置没有链接到至少一个点车辆无法到达车辆四档电量阈值、最大速度、集成级别忘记设置集成级别车辆一直处于“忽略”状态点是最基本的逻辑映射。它有三类其中“停车位置”是车辆在无订单时可以长期停靠的点“停靠位置”是处理订单时临时停靠的点“报告位置”则只是个过路上报点车辆不会被命令到那里也不允许在那停车。如果你建了一条只由报告位置组成的路线路由器会直接判定无法路由因为车辆没有落脚点。点的车辆方向角也要注意0 度在 3 点钟位置正值表示顺时针旋转这和很多 CAD 坐标系习惯相反建模时容易顺手写错。位置和点是两个完全不同的东西。点位是车辆在拓扑中的逻辑映射位置则是标记车辆可以执行特殊操作装卸货、充电、开防火门的地理概念。每个位置至少要链接到一个点车辆才能到达位置类型定义了这个位置允许的车辆操作和外设操作。路径外设操作部分运行触发器支持 BEFORE_MOVEMENT 和 AFTER_MOVEMENT 两种取值配合完成要求标志——如果要求在路径前完成外设操作且标志为 true车辆就得在路径源点等如果要求在路径后完成就得在目的地等。这个机制非常适合闸机、自动门这类需要和车辆互锁的场景。2.3 块、图层与通用属性被多数人跳过但迟早要用的三个旋钮块是用于限制车辆活动范围的地理区域调度scheduler在分配资源时会考虑块约束避免车辆驶入冲突区域。图层和图层组则纯粹是为了组织和显示——你可以把行驶路径放在基层把停车位放在上层显示时自由开关不会污染模型本身的逻辑。真正值得花时间理解的是通用属性机制。每个模型要素都支持“唯一名称”和“通用属性”通用属性本身没有固定含义完全由项目自己定义。手册第六章也提到可以用模型要素属性保存特定于项目的数据比如某个点对应的 PLC 地址、某个车辆负责的产线编号。这其实是一个很聪明的扩展点不需要改内核代码就能把业务元数据塞进模型里供自己的客户端读取。3. 动手跑通一个运输订单模型编辑、内核启动与撤销操作3.1 构建工厂模型从添加点到复制布局坐标构建模型的入口是模型编辑器。启动前请确保已安装 JRE 13 并且 JRE 的 bin 目录已加入环境变量 PATH否则发行版自带的启动脚本可能找不到 java。手册特意警告部分商业 JRE 发行版与内置的界面库存在兼容问题建议优先选用社区维护版 JRE。我一般会在部署文档里把这一步放在最前面因为它能解释掉后面一大堆莫名其妙的启动失败。启动编辑器后右键空白处即可添加点。先别急着连路径我建议按这个顺序梳理添加点并设置类型。默认是停靠位置这是最安全的起点。把装卸货、充电位置设为停靠位置把车辆长期待命的地方设为停车位置。连接路径。选中两个点拉出路径并在属性面板中填写长度、最大行进速度、最大倒车速度。长度是路由成本计算的重要输入实测中很多生产模型这里的数值都拍脑袋填导致系统算出的“最短路径”和实际时间对不上。添加位置并链接到点。位置必须链接到至少一个点否则调度程序无法把车辆引导过去。用图层组织显示。比如把路径放在“行驶层”把停车位放在“停车层”。这样后续运维时看图会清爽很多。保存工厂模型然后加载到内核中。这里有一个绕不开的坑布局坐标系与模型坐标系。布局坐标只决定编辑器里的显示位置模型坐标才是真正发送给车辆的数据。如果你在编辑器里拖动了点的显示位置模型坐标不会跟着变。要同步可以全选后用全局菜单里的“将模型值复制到布局”或只对单个要素右键操作。我见过有人现场把模型坐标手动改错了车辆在实际场地里直奔墙壁这种错误只能靠这步同步操作来避免。3.2 启动内核与挂载车辆驱动通信适配器是绕不开的一环模型建好后启动内核再用操作台连接。内核启动前需要确认车辆驱动已经就绪。openTCS 本身不包含任何真实车辆的通信协议实现——这是新手最容易误判的地方。它通过“通信适配器”把内核抽象接口转成你的车辆能懂的报文类似于操作系统里的设备驱动。所以实际项目中要么车辆厂商提供适配器要么自己开发要么先用虚拟车辆顶替来联调流程。常见的启动流程是分别启动内核、模型编辑器或操作台# 确保 JRE 13 已经可用 export PATH/path/to/jdk-13.0.2/bin:$PATH # 进入 openTCS 发行目录按顺序启动内核和客户端 ./startKernel ./startModelEditor ./startOperationsDesk 这里的让进程在后台运行避免终端阻塞。PATH 变量决定了启动脚本能否找到 java如果经常遇到“找不到或加载主类”的错误先检查这一句配置。发行版的脚本命名通常是 startKernel.sh 这类而内核控制中心则负责把驱动挂载到指定车辆上——在 KCC 的车辆视图中你可以把某个适配器分配给某辆车并监视它们之间的通信状态。3.3 创建与撤销运输订单操作台与外设作业的闭环当车辆驱动状态变成可用后就可以在操作台创建运输订单了。运输订单的核心是告诉系统“让某辆车或任意车辆把某个位置的负载搬到另一个位置”。操作台支持手工创建单条订单也支持连续创建一批订单运输订单序列可以把多个订单按顺序压入队列适合连续搬运场景。撤销订单同样在操作台完成。这个功能在调试阶段几乎是后悔药——订单发错了、车辆卡住了、路线被锁了都可以先撤销再重发。需要注意的是撤销订单和暂停车辆是两个动作撤销是对订单本身操作暂停是对车辆的状态操作两者不要混淆。车辆运行中可以从运行系统移除也可以暂停和恢复手册里都有对应菜单但我在现场的习惯是先暂停再撤销订单最后移除驱动避免系统在移除过程中还在派单。外设作业是另一个独立通道。它和运输订单并行运作面向的是与位置映射的外设设备比如充电桩、自动门。外设作业的执行需要经过默认外设作业调度程序的路由有一个“预留令牌”机制——同一时间一个外设只能被一个作业占用。排障时如果发现外设作业一直排队先看令牌是不是被别的作业占着这是新手最容易头晕的地方。4. 默认策略的逻辑调度、路由、资源分配与外设令牌如何协同4.1 默认调度程序车辆空闲、低电、远行时的三个选择调度这个英文词在 openTCS 里有两个层级很容易混淆。一个是 dispatcher负责“把运输订单分配给合适的车辆”另一个是 scheduler负责“为车辆的行驶过程分配资源、避免碰撞”。为了讲清楚我分开说。默认 dispatcher 处理三个典型决策没有订单时车辆去哪、低电量时车辆去哪、有多辆车可选时优先派哪辆。没有订单时dispatcher 会让车辆去默认停车位置这是模型的停车位置之一可以设置优先级去选择更优的停车点。电量方面车辆有四个电量阈值临界、良好、完全充电、充分充电dispatcher 会依据这些阈值决定车辆何时必须充电、何时可以停止充电。你可以在车辆属性里按实际电池特性配置这四个值不要照搬示例参数。4.2 路由器与成本函数距离之外还有速度和锁定默认路由器用于寻找最佳路线。它的成本函数并不只取决于路径长度路径的最大行进速度和最大倒车速度同样会进入计算。这在真实场景中很关键——两条路物理长度相同但一条限速 0.5m/s另一条限速 1.5m/s路由器会倾向于选后者。路径的锁定标志则会在计算路由时直接禁用该路径适合在封闭施工、故障维护时临时屏蔽路段。另外路由组是给特殊车辆用的约束机制。你可以把一组路径划入某个路由组并配置某辆车只走这个路由组内的路径实现“大车走大路、小车走小路”的隔离效果。这在混合车队场景下非常实用默认实现也完全支持这类用法。4.3 调度scheduler的公平性防碰撞与资源释放时机资源调度解决的是交通管理问题核心是避免车辆相撞。scheduler 为车辆分配路径和点区域等资源并决定何时释放。默认实现的公平性策略很重要它保证长期执行的调度不会让某辆车一直被饿死即不会因为部分车辆频繁占用资源导致其他车辆永远无法通过。如果你在调试中发现某些车辆长时间停在原地不动但系统没有任何报错优先级和资源释放时机是最先要怀疑的两个点。外设作业调度程序也有一套自己的调度机制这里再次出现“令牌预留”。外设作业在执行前会先预留外设令牌令牌拿不到就排队等待。这其实是在运输订单调度之外又加了一层外设资源的仲裁避免两辆车同时要求同一个充电桩或同一扇防火门动作。调试时遇到外设作业“队伍很长但一动不动”先去看令牌是否被某个异常作业占用。5. 配置边界与避坑排查5.9 手册里最容易被略读的 8 个细节5.1 四个高频踩坑记录现象、原因与解决我在用 openTCS 搭调度环境时翻过不少车下面四条最具代表性都来自实际排障过程。坑一启动脚本闪退日志出现界面库相关异常现象执行 startKernel 后进程立刻退出日志里抛出一段和内置界面库Docking Frames相关的异常。原因使用了与 openTCS 不兼容的 JRE 发行版。手册在系统要求里专门警告过部分商业 JRE 与 openTCS 依赖的界面库存在兼容限制不是所有 Java 环境都能直接跑。解决换用社区维护版 JRE 13并把 JRE 的 bin 目录加入 PATH。这类问题不是代码问题而是运行时环境选型问题换环境通常立竿见影。坑二运输订单被分配了但车辆走到一半停住不走了现象车辆领取订单后开始移动到了某个点就不再前进操作台上也没有明确的告警。原因目的地或路径上的点类型配置不当。最常见的是把目的点设成了报告位置report 点不允许车辆停靠scheduler 无法为它分配最终资源另一种情况是位置没有链接到点车辆认为目的地不可达。解决在模型编辑器里检查目的点的类型确认它是停靠位置或停车位置并检查位置的点链接集合保证至少有一个点与位置关联。改完模型后要重新加载到内核。坑三在编辑器里拖动点后车辆实际坐标全乱了现象操作台显示的地图布局变了但车辆到达的实际位置和显示位置对不上。原因布局坐标系和模型坐标系没有被同步。拖动点只改变布局坐标为了显示而调整了展示视图模型坐标纹丝不动。解决选中被拖动的要素右键菜单选择“将模型值复制到布局”或者在全局菜单里做整体同步。这个动作应该成为建模流程的常规收尾步骤。坑四外设作业一直排队没有任何执行动静现象运输订单正常但关联的防火门、充电桩等外设作业始终处于等待状态。原因外设令牌被其他作业占用且未释放。默认外设作业调度程序依赖令牌预留机制令牌被占后后续作业只能排队。解决检查占用令牌的作业在操作台撤销或强制完成它。如果系统里存在僵尸作业定期清理订单池能有效避免这类问题。5.2 配置项地图内核配置、订单池、SSL 与虚拟设备手册第五章列出的配置项非常多但真正在部署阶段需要逐一确认的没有那么多。我把它们分成四类整理了一张配置地图配置分组作用部署时的关注点内核配置定义内核本身行为如是否自动加载模型启动自动加载避免人工点击误操作订单池配置管理订单的存放与清理策略配置周期清理防止完成订单堆积导致状态查询变慢默认调度程序/路由器/外设调度配置调整公平性、停靠选择、成本计算电量阈值、停车位置优先级、成本函数权重SSL 配置客户端与内核之间的通信加密涉及证书配置和密钥库跨机器部署时必查Web API 与 RMI 配置同样值得关注。如果准备对接仓库管理系统Web API 配置项决定服务端口和鉴权方式如果现场网络环境复杂建议先在内核控制中心里确认 RMI 端口能互通再考虑 SSL 加密。RMI 接口和 SSL 配置项往往被忽略但实际跨机器部署时最常见的失败原因就是端口不通或加密配置不一致。配置项本身不是越多越好。虚拟车辆配置项和虚拟外设配置项是调试时的宝贵工具没有真实硬件也能完整跑通调度流程。手册第六章也提到了配置虚拟车辆特征我建议所有新项目在拿到真车前都用虚拟车辆先跑一遍把模型和订单流程调到稳定再说。6. 进阶验证用虚拟车辆和自动启动把部署跑成习惯6.1 先虚拟车辆再上真车启动链路验证虚拟车辆最大的价值是让你在干净的软件环境里验证整套调度链路。配置一两台虚拟车辆加载工厂模型启动内核然后在操作台创建一个运输订单观察车辆是否从起点移动到终点。我每次部署新现场都会做这样一轮试用启动内核确认日志无异常。通过内核控制中心挂载虚拟车辆驱动。在操作台下发一个从 A 点到 B 点的运输订单。观察操作台地图上虚拟车辆的状态迁移和位置变化。撤销订单确认车辆能回到停车位置。如果虚拟车辆能顺利完成“建单-派车-到达-撤销”的闭环再上真车测试通信协议排查范围就会立刻缩小到真正的硬件链路。6.2 自动启动与会话收尾对于现场长期运行的机器手动点按钮启动每个进程不是一个专业做法。手册介绍了配置自动启动的方法把启动脚本注册为系统服务或用调度器触发并让内核在启动时自动加载指定的工厂模型。我在生产环境里习惯把“自动加载模型”和“自动选择特定车辆驱动”写进启动流程这样即使某台电脑重启过整个调度系统也能自行恢复。跨机器部署时SSL 加密和防火墙端口放行是最耗时的部分。建议先在不加密的配置下确认 RMI 和 Web API 能连通再逐层加上加密避免一开始就把问题复杂化。从那以后我每次换新环境部署 openTCS都会强制自己先走一遍“虚拟车辆跑满订单闭环、配置自动启动、再验证加密通信”的流程这套顺序帮我挡掉了大量现场翻车的可能希望帮到你。本文还有配套的精品资源点击获取