简介：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，都会强制自己先走一遍“虚拟车辆跑满订单闭环、配置自动启动、再验证加密通信”的流程，这套顺序帮我挡掉了大量现场翻车的可能，希望帮到你。
本文还有配套的精品资源，点击获取
