简介这是一份面向AGV调度系统实施与运维人员的 openTCS 5.9 中文用户手册适合需要部署或定制开源运输控制系统的读者。手册系统梳理了 openTCS 的软件目的、Java 运行环境要求与 Apache 2.0 许可说明并对控制台、运输任务管理器、车辆控制器及工厂模型中的点、路径、位置、位置类型、车辆、块、图层等核心概念逐一展开配有目录与章节导览便于快速定位操作要点。内容还延伸到运输订单、订单序列、外设作业与公用要素属性等运行机制能够帮助用户理解 AGV 调度逻辑、完成基础建模与任务配置。压缩包为单个 PDF 文档大小约 13.31MB共 1 个文件阅读与离线查阅都很方便。该手册已有 592 人浏览学习对正在选型或上手 openTCS 的工程师具有实用参考价值尤其适合按章节循序渐进地学习从环境准备到工厂建模、任务分配与监控的完整流程。1. openTCS 5.9 中文用户手册AGV 调度系统RCS的开源黑匣子怎么打开做 AGV 调度系统RCS选型时最头疼的不是算法写不出来而是手里的车辆协议和调度框架能不能对上。openTCS 就是专门解决这个问题的开源框架它把车辆路由、订单分派、交通管理这些核心算法做成与车辆无关的模块你只需要为你的 AGV 写一个通信适配器。这份 5.9 中文版手册把官方英文文档的目录、系统组件、工厂模型要素、默认策略和配置项都翻译并整理成了中文对从零接触 openTCS 的实施工程师来说价值在于不用边查词典边对着英文文档猜「调度 dispatcher」和「调度 scheduler」到底谁是谁。适合做 AGV 项目选型、入场调试、或者二次开发前通读框架结构的人。2. 系统结构与工厂模型先搞清楚 Kernel 里三个「调度」的职责边界openTCS 不是一套开箱即用的成品软件而是半成品框架。它自带默认策略但默认策略不一定适配你的项目所以手册第二章先讲系统和模型目的就是让你知道哪些能改、从哪改。我见过不少新手直接跳过这一章结果到配置阶段就翻车不知道 dispatcher、router、scheduler 的职责边界三个模块的日志混在一起看定位问题全靠猜。2.1 客户端-服务器架构Kernel 与三个客户端的分工openTCS 以独立进程方式运行多个组件。Kernel 是服务器进程负责维护工厂模型、处理运输订单、为车辆规划路线模型编辑器、操作台、内核控制中心是三个随发行版提供的客户端。模型编辑器用来离线建立工厂模型操作台用来在运行期间可视化模型并创建订单内核控制中心用来给车辆绑定驱动程序、查看车辆状态和低级通信。如果你需要对接仓库管理系统openTCS 还提供 Web API能创建和撤销运输订单、轮询订单状态这部分在 5.9 手册的配置章节里有专门说明。理解这个架构的意义在于定位问题模型加载不上先查模型编辑器到 Kernel 的连接车辆不执行订单先查内核控制中心里驱动是否绑定订单积压才去查 Kernel 内部的 dispatcher 逻辑。客户端和 Kernel 可以用 RMI 通信也可以跨机器部署手册高级使用部分专门讲了「在不同系统上运行内核和客户端」的做法配置项集中在 RMI 内核接口和 SSL 加密这两节。2.2 工厂模型最小骨架点、路径和位置工厂模型是对实际行驶路线和装卸站的抽象。点是车辆的逻辑映射位置分三种类型停靠位置是默认类型车辆到达后要报告处理完订单才能离开报告位置只用来上报经过车辆不会被命令停在这里停车位置用来长期停放车辆。路径连接两个点有长度、最大行进速度、最大倒车速度还有锁定标志——锁定的路径在路由器计算时不会被使用。位置是标记特殊操作的地点比如装卸货、充电。位置必须关联到至少一个点车辆才能到达这个位置。位置有个容易忽略的点位置类型决定了允许执行哪些车辆操作和外设操作。比如你把充电操作放在某个位置类型上但该位置类型没有勾选充电操作那调度程序永远不会把充电订单分给经过这里的车。这个坑在手册 2.2.3 和 2.2.4 里其实写得很清楚只是很多人翻太快。2.3 块、图层和图层组大规模地图的横向切分块Block是若干路线元素的集合用来划分地理区域可以用于限制活动范围避免车辆驶入特定区域。图层和图层组则是组织与可视化手段不同图层放不同类型的元素图层组再归类。实际项目中我会把设备区、充电区、暂存区分到不同图层调试时按图层开关显示比全屏密密麻麻的点路径舒服得多。创建模型时还有一个坐标系统需要区分布局坐标系和模型坐标系。前者只影响图形显示后者参与车辆实际导航数据。这两套坐标互不关联你可以在布局里把一条很长的路径显示得短一点但模型坐标必须和车辆驱动需要的真实坐标一致。手册给了两个同步操作全局同步可以选「将模型值复制到布局」或「将布局值复制到模型」单个要素右键菜单也能同步。这个操作我没少用因为从现场测绘回来的点往往是模型坐标拖布局图时一不小心就拖岔了。2.4 车辆集成级别与电量阈值系统对 AGV 的信任程度车辆要素里有四个关键属性组电量级别、速度、集成级别、允许分配订单的状态。电量级别分临界、良好、完全充电、充分充电调度策略根据这些阈值决定何时强制充电、何时可以停止充电。集成级别则分为忽略、关注、尊重三档忽略状态下的车辆完全不下发订单也不显示关注状态下会显示报告位置但不分配资源尊重状态下才正常参与调度。这个集成级别只能在操作台调整模型编辑器改不了很多刚上手的同事会在模型编辑器里找半天。这几个属性的意义在于openTCS 把「车辆物理存在」和「系统逻辑参与」分开了。现场车辆故障时不用在模型里删掉它只把它降级到「关注」状态就能让调度程序绕开它又保留它的位置显示。手册第四章的默认调度程序策略也依赖这些属性比如停车位置选择会优先考虑电量状态。理解这些再去看配置项就不会把「充电电量阈值」和「停止充电阈值」的含义弄混。3. 从模型编辑器到运输订单不写一行代码跑通 openTCS手册第三章是操作章节也是我建议所有新人先做一遍的「最小闭环」。所谓最小闭环就是建一个三点的工厂模型配置一辆虚拟车辆创建一条运输订单看它自己跑过去。整个过程不涉及任何真实 AGV 硬件openTCS 自带虚拟车辆驱动所以任何人只要有 JRE 13 就能跟着手册复现。3.1 启动模型编辑器与内核先确认 Java 环境openTCS 5.9 对 Java 版本的要求是 JRE 13。注意官方在系统要求里明确警告由于界面库限制部分商业 JRE 与 openTCS 不兼容建议使用社区维护的 JRE。这个警告不是玄学我遇到过装在商业 JRE 上模型编辑器窗口闪退换成社区版 JRE 后一切正常。启动前把 JRE 的 bin 目录加入 PATH然后进入发行版目录执行启动脚本# 假设发行版解压在 /opt/opentcs-5.9 cd /opt/opentcs-5.9 export PATH$PATH:/opt/jdk-13/bin ./opentcs-kernel.sh 这里的opentcs-kernel.sh是内核启动脚本实际文件名以你解压出的发行版为准表示后台运行。启动后观察log/子目录下有没有生成内核日志如果日志里出现 Java 版本相关的异常多半是 PATH 里的 JRE 不对。我一般会先手动执行java -version确认版本再启动。模型编辑器是独立客户端同样在 bin 目录下启动。它默认连接本机内核如果内核没起来模型编辑器也能打开但加载模型到内核时会报连接失败。所以顺序应该是先启动内核再启动模型编辑器。这个顺序写进你们团队的新人操作规范里能省不少排查时间。3.2 构建工厂模型添加点、路径和位置类型模型编辑器里的操作逻辑和通用绘图工具相似。先在空白区域添加几个点然后用路径工具连接点。手册 3.1.2 详细讲了添加要素的步骤我这里强调三个容易漏的参数第一点的类型。默认是停靠位置但如果你把某些点设成报告位置而整条路线只有报告位置路由器会认为没有可以停车的位置导致无法路由。第二路径的最大速度和倒车速度。这两个值参与路由成本计算如果你不填或填 0路由器可能把这条路径当成最优路径现场车辆实际速度又跟不上订单超时。第三位置关联点。你添加一个位置但没把它链接到任何点调度程序认为该位置不可达订单永远留在待处理列表。添加完要素后保存工厂模型。手册里用的是.xml格式默认保存到data/子目录。模型文件就是内核和模型编辑器共享的「地图文件」建议用版本管理工具管理别只留在本机。我习惯每次修改前复制一份毕竟布局坐标和模型坐标同步用的是按钮操作点错一步不是 CtrlZ 能救回来的。提示模型编辑器里的坐标同步操作不可逆改之前一定要先另存一份模型文件。3.3 配置车辆与驱动程序虚拟车辆先跑通没有真实车辆时openTCS 提供的虚拟车辆驱动能模拟一辆车的行为这非常适合验证模型逻辑。步骤如下在内核控制中心里找到车辆列表新建一辆车辆然后在驱动选择里关联虚拟车辆驱动。手册 3.2.2 的「配置车辆驱动程序」讲的就是这个过程。关于驱动的理解openTCS 内核只提供抽象接口你的车辆用什么协议——是 TCP、串口还是自定义报文——都由通信适配器即车辆驱动程序处理。驱动在内核和车辆之间做协议转换类似操作系统设备驱动的角色。同一套 openTCS 实例可以同时接入不同通信协议的车辆只要每个车型都有对应驱动模块。这也是 openTCS 作为 RCS 系统最大的卖点调度算法和车辆特性解耦。配置完成后车辆会进入某个集成级别。默认状态下车辆可能是「关注」级别你还得在操作台里把它改成「尊重」级别否则订单不会分给它。这个操作只能在操作台做模型编辑器里找不到这个按钮。3.4 创建运输订单与外设作业运行闭环的最后一公里操作台的功能是可视化和订单管理。创建运输订单时你可以在模型上点击源点和目的点openTCS 会生成一个带逻辑顺序的运输订单并交给 dispatcherdispatcher 选择合适车辆router 计算路径scheduler 分配路径上的点资源。这个过程在菜单栏和右键菜单都有入口手册 3.2.3 到 3.2.5 给了连续创建订单的说明。外设作业是另一类任务位置上的外设设备比如充电桩、防火门需要在车辆经过时执行动作。外设作业挂在路径或位置上路径的外设操作有 BEFORE_MOVEMENT 和 AFTER_MOVEMENT 两种触发器配合完成要求标志可以让车辆在动作完成前等待。这个机制在对接自动门时非常关键要是门没开到位就让 AGV 过去现场就要打电话报修了。撤销订单也有固定路径操作台应用程序里选中正在执行的订单执行撤销命令。撤销后 dispatcher 会重新调度车辆执行其他任务scheduler 会释放已分配的资源。注意撤销订单和车辆直接停车不是一回事撤销是逻辑层面的操作车辆最终停在哪还要看它当前正在执行哪一步。4. 默认策略与配置参数dispatcher、router、scheduler 都在替你做什么openTCS 处理运输订单时内核里有三个主要策略模块协作订单调度程序dispatcher决定哪个车辆做哪个订单路由程序router计算到目的地的最佳路线资源调度程序scheduler管理点、路径等资源分配避免车辆相撞。手册第四章把这几个模块的默认策略逐一讲透这一章是二次开发必读。4.1 默认调度程序停车位置选择和充电位置选择首先注意手册里的“默认调度程序”在第四章出现了两次一次是 4.1 的订单调度 dispatcher一次是 4.3 的资源调度 scheduler。这是中文翻译的坑。4.1 的默认调度程序处理的是没有订单时车辆去哪、电量低时去哪充电。默认停车位置选择会遍历所有停车位置根据路径成本和车辆状态打分停车位置优先级可以在模型里配置比如把靠近出口的停车位设为最高优先级。默认充电位置选择则根据车辆电量阈值决定是否进入充电流程。理解这个逻辑之后你会发现车辆空闲乱停的问题多半不是算法错了而是模型里停车位置类型没设对或者优先级没配。手册 4.1.2 明确说了停车位置优先级是参与选择的因子之一但优先级高低最终由成本函数换算不是直接选优先级最高的。所以不要指望给某个车位设了最高优先级所有车都去抢它。4.2 默认路由器成本函数与路由组路由器默认按路径长度、行驶速度、倒车等因素计算成本。手册 4.2.1 提到成本函数默认实现是把路径的成本当作一个可配置的加权值你可以通过配置项调整不同因素的权重。比如你更看重时间而不是距离就把速度相关的权重调大。但注意成本函数是整个路由的核心改之前最好先在小模型上仿真对比否则很容易出现「绕远路反而被优先选」的奇怪现象。路由组是一个偏进阶的机制把部分路径划分到不同路由组可以限制某些车辆只在特定区域内路由。这对多车型场景很实用比如叉车不能上高架库区域通过路由组就能隔离。手册 4.2.2 有说明但配置示例不算多需要你自己结合工厂模型试。4.3 资源调度程序分配与释放资源的公平性资源调度 scheduler 才是真正管交通的模块。它负责给车辆的行驶路径分配点、路径等资源防止两辆车同时占用同一路段。默认策略下资源按订单请求的顺序分配释放则是在车辆离开某个点后立即释放。手册 4.3.3 专门提了调度的公平性默认实现尽量先到先得但不会考虑订单优先级如果现场有高优先级订单插队需求默认策略是不够的需要二次开发。我遇到过这样一个问题两辆 AGV 在单行道双向行驶默认 scheduler 只保证不碰撞不保证不阻塞。如果 A 车占用了中间点B 车在另一头等A 车又需要 B 车让路才能继续就会出现死锁。手册没有给出死锁检测方案但 4.3.2 的资源释放逻辑能解释根因资源只在车辆离开点后释放如果车辆停在点上等待订单资源就被它一直占着。现场处理这个问题的常见做法是设置更长的心跳超时或者把停车位置放在主路径之外。4.4 内核配置项地图订单池、外设调度、Web API手册第五章列出所有配置入口。配置通常改安装目录下的config子目录里的配置文件改完重启内核生效。我按用途把主要配置项分成几类用表格列一下配置域作用常见调整点内核应用配置基本端口、日志级别、模型目录监听端口、模型自动加载开关订单池配置管理待处理订单数量与清理最大订单数、订单保留时间默认调度程序配置停车/充电策略、空闲车辆行为停车位搜索开关、空闲超时默认路由器配置路由成本权重、路径选择倒车惩罚、路由组限制默认外设调度程序配置外设作业的令牌预留令牌超时时间Web API 配置对外 HTTP 接口启用开关、认证方式SSL 配置客户端与内核加密通信证书路径、启用标志每个配置域在手册第五章都有对应的子目录描述比如 5.2.2 订单池、5.2.3 默认调度程序、5.2.6 管理 Web API。我不是让你背参数名而是建议先通读一遍知道自己能改什么再按项目需要找具体键名。直接改配置的代价是如果键写错内核启动时会报配置解析异常日志里会指出配置项名称照着修即可。配置虚拟车辆也是在这一章5.2.10 虚拟车辆配置项、5.2.11 虚拟外设配置项。虚拟车辆和真实车辆的区别只在驱动层调度逻辑完全一样所以做算法验证时我强烈建议用虚拟车辆先跑一遍配置变更。改调度策略前先虚拟跑一轮比直接上实车安全得多。日志文件是配置排错的晴雨表。内核、模型编辑器、操作台各自有log/子目录报问题时把对应日志拉出来基本能定位到模块。手册 1.5 支持章节也提醒用户提交日志和工厂模型可见官方把日志当作第一排错依据。我自己的习惯是每次改配置前先清一次日志改完再看 diff这样改了什么、报了什么错对得上。5. 避坑openTCS 5.9 安装与运行中的五个典型翻车现场手册本身把步骤写得很清楚但实际操作中的坑大多来自环境差异和概念混淆。这一章我整理了五个高频问题每条都按「现象 → 原因 → 解决」来写都是我或同事在项目中实际踩过的。5.1 启动脚本秒退没有任何提示窗口现象双击启动脚本或命令行执行后窗口一闪而过内核和客户端都没起来。原因最常见的是 PATH 里的 Java 不是 JRE 13。openTCS 5.9 依赖 Java 13 的某些特性和库低版本 JRE 根本跑不起来另外某些商业 JRE 因界面库限制也会启动失败不兼容问题在官方系统要求里明确提过。解决先手动执行java -version确认版本是 13如果不是下载并安装社区版 JRE 13把它的 bin 目录放到 PATH 的最前面。然后到发行版的log/目录看启动日志日志末尾会有具体异常信息比瞎猜强。从那以后我每次部署新机器都强制先java -version再开脚本。5.2 布局坐标系和模型坐标系错位车实际走的位置和地图显示不一致现象操作台地图上车辆显示已经到达目标点但车辆驱动收到的坐标数据和目标位置差了几米。原因布局坐标系只负责显示模型坐标系才下发到车辆。建模时拖动点改变了布局坐标但模型坐标没有跟着变或者反过来。手册 2.2.1.1 专门讲了这两套坐标的同步方法。解决在模型编辑器里选中要素右键菜单选择「将模型值复制到布局」或「将布局值复制到模型」把两套坐标拉齐。全局同步用菜单「操作›复制模型值到布局」也行。注意同步是不可逆的操作前先保存模型副本。5.3 运输订单永远在待处理列表调度程序就是不分配车辆现象创建订单后订单状态一直是待处理车辆没有动作dispatcher 日志也没有报错。原因三类可能按概率排序——车辆集成级别还是「关注」或「忽略」位置没有关联到任何点订单里选择的操作在位置类型里没被允许。这三类在操作台的车辆状态、模型编辑器的点位置属性里都能看到。解决先把车辆集成级别改成「尊重」然后检查订单源点和目的点是否都关联了可达点再看位置类型是否勾选了对应操作。如果都正常看 dispatcher 日志里的车辆选择记录它会告诉你车辆被跳过时考虑了什么因子。这个排查顺序我已经固化到脚本里项目上都照这个查。5.4 路径被锁定车辆怎么都绕不过去但路由器不报错现象某段道路维修在模型里把路径的锁定标志设上但车辆还是被规划经过那条路径。原因锁定标志告诉路由器「不要用」但如果你锁定的是路径本身而该路径是两点之间唯一连接路由器没有其他路径可选就会照样走锁定路径只是成本会增加。手册 2.2.2 里「锁定标志」描述没有强调这是「不作为首选」默认路由器并不绝对禁止使用。解决临时封路时应该同时把路径锁定并在相关点上加禁行标记或者直接调整连接关系确保存在可行替代路径。更稳妥的做法是把路径对应的实际物理段放到一个块里临时禁用整个块。这个技巧在手册块的部分没有展开但实际项目非常有用。5.5 RMI 或 SSL 配置错客户端连不上远程内核现象内核在服务器上本地模型编辑器连接时报 RMI 或 SSL 握手异常日志里能看到证书或端口相关报错。原因跨机器部署时客户端配置的内核地址、RMI 端口、SSL 证书路径必须和内核侧一致。手册 5.2.8 和 5.2.9 分别给了 RMI 和 SSL 配置项很多人只改了内核端没改客户端端的连接配置。解决先在同一台机器上用默认配置确认内核能起再改远程连接。SSL 要确保客户端信任的证书和内核用的证书是同一套别混用自签名证书。我把证书路径和端口号写成一个环境变量文件部署时统一替换避免每台客户端手改。这类问题还有一个特征是日志里会有明确的模块名称比如 RMI 注册失败、SSL 握手失败照着模块名去查手册对应配置节即可。6. 进阶用模型要素属性做项目定制顺手验证自动充电策略手册 6.8 提到「为特定于项目的数据使用模型要素属性」这个能力用好之后可以少写很多定制算法。每个模型要素点、路径、位置、车辆除了系统预置属性还能挂自定义属性比如custom.zone、customer.priority。这些属性保存在模型文件里内核的算法模块可以通过 API 读取从而实现项目级数据注入。我的做法是把生产现场的工艺参数沉淀成模型属性而不是把每个现场场景都写成硬编码。比如某个位置只允许特定类型的车辆停靠就在位置属性里加vehicle.typeheavy然后在 dispatcher 的定制代码里过滤车辆。这样换项目时只需要改模型文件算法代码几乎不用动。手册 6.8 的说明比较简短但「属性名-属性值」的设计足够解决大多数业务标记需求。自动充电策略的验证也可以完全在虚拟环境里做完。你只需要在车辆属性里设置临界电量、良好电量、完全充电、充分充电四个阈值然后给充电位置设置好位置类型和外设操作再用虚拟车辆模拟低电量状态观察 dispatcher 是否生成充电订单、车辆是否移动到充电位置、电量恢复到哪个阈值才停止充电。这个闭环我在做项目验收时都会跑一遍比实车测试快得多。具体验证步骤先在模型编辑器里建好充电位置位置类型勾选「充电」操作车辆属性里把临界电量设为 20%、充分充电设为 80%运行内核后通过操作台把车辆电量手动改到 15%虚拟车辆支持下发模拟电量状态然后创建任意运输订单观察 dispatcher 是否把充电订单插到运输订单之前。如果充电逻辑没触发重点检查三处位置类型是否允许充电操作、充电位置是否关联了可达点、车辆集成级别是否尊重。整个过程不需要真实 AGV十分钟就能得出结论。这个技巧让我在多个项目上省了大量现场调试时间。从那以后我每次做新项目都强制把「模型属性规划」放在建模第一步先把业务参数塞进模型再写调度逻辑。如果一上来就写代码后期换现场就是灾难。希望帮到你去把你的 AGV 调度模型跑起来吧。本文还有配套的精品资源点击获取