# openTCS: an open control platform for AGV and mobile robot fleets

> openTCS is a Java platform for controlling fleets of automated guided vehicles and mobile robots, providing the routing, dispatching and scheduling layer that a multi-vehicle system needs, with VDA5050 support built in and a communication adapter concept for everything else. It is maintained by Fraunhofer IML.

**openTCS/opentcs** — The open Transportation Control System (by Fraunhofer IML)

- Repository: https://github.com/openTCS/opentcs
- Website: https://www.opentcs.org/
- Stars: 593 · Forks: 201
- Language: Java
- License: not declared
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/opentcs-opentcs

## What openTCS is and who runs it

openTCS, short for open Transportation Control System, is a free platform for controlling fleets of automated guided vehicles and mobile robots. The stated ambition is that it should generally be possible to control any automatic vehicle with communication capabilities, while acknowledging that AGVs are the main target. The project is maintained by the openTCS team at the Fraunhofer Institute for Material Flow and Logistics, which is the institutional reason it has stayed alive across major versions.@@P@@The positioning matters for how you read the codebase. openTCS is not a robot controller and not a vehicle simulator. It is the layer above them: the part that decides which vehicle should do what, when, and by which route, and that keeps a fleet of them from colliding with each other in the aisles. The README describes it as a framework, or an implementation of the basic data structures and algorithms needed for running an AGV system with more than one vehicle.@@P@@That framing also explains the emphasis on genericity. The project tries to be as generic as possible to allow interoperation with vehicles of practically any vendor, because an integrator's fleet is rarely homogeneous. The cost of that generality is the adapter work described later, which is where most of the effort for a non-standard vehicle goes.@@P@@The software runs on the Java platform version 21, with the Adoptium distribution recommended, and the README states that all libraries required for compiling or using it are freely available. The project is version 7.x, with Release 7.4 on 2026-08-12 and Release 7.3 on 2026-05-26, and the repository was last pushed on 2026-09-17.

## The kernel: routing, dispatching and scheduling

The three algorithms named in the README, routing, dispatching and scheduling, are the actual content of the platform, and separating them is the design decision worth understanding before you integrate anything.@@P@@Routing is the path problem. Given a plant layout with locations and the vehicles that can reach them, the router computes how a vehicle gets from where it is to where it has to be. Dispatching is the assignment problem: which of the available vehicles should take which of the pending transport orders. Scheduling is the timing problem: when a vehicle should start, wait, and how long it should stay where it is.@@P@@These three interact, and that is the hard part. A dispatcher that assigns a vehicle to an order without checking the router may produce a job the fleet cannot execute in time, and a scheduler that ignores the current traffic state creates queues that the plant cannot absorb. openTCS implements these as a kernel, the opentcs-kernel module, and the README is explicit that depending on your needs you might also need to adapt algorithms or add project-specific strategies.@@P@@The strategies are a separate module, opentcs-strategies-default, which is the clearest signal that the default behaviour is meant to be replaced rather than merely tuned. A plant with unusual traffic patterns, a machine that must be served in a fixed order, or a shift pattern that changes the priorities is exactly the case where the default routing and dispatching give way to something specific to your site.@@P@@Around the kernel sit two extension points for exposing it: opentcs-kernel-extension-rmi-services and opentcs-kernel-extension-http-services, which is how other systems reach the control logic. The RMI extension follows the classic Java remote method invocation approach, and the HTTP extension is the one to look at if your integration is not written in Java.

## Vehicle integration: VDA5050 out of the box, adapters for everything else

The integration story has two clearly separated paths, and which one you are on determines the size of your project.@@P@@The first path is VDA5050. The README states that vehicles supporting VDA5050 can be integrated with openTCS without additional programming, and there is a dedicated module for it, opentcs-commadapter-vda5050. VDA5050 is an industry interface specification for AGV communication, so a vehicle that implements it needs no bespoke code on either side.@@P@@The second path is everything else, and the README is direct about the cost: for other vehicles it is usually necessary to at least create and integrate a vehicle driver, called a communication adapter in openTCS speak, that translates between the abstract interface of the openTCS kernel and the communication protocol your vehicle understands.@@P@@That translation is the entire integration surface. The kernel speaks in abstract terms, and the adapter is where those terms become bytes on a serial line, a TCP socket or whatever your controller exposes. The repository shows the pattern with two loopback adapters, opentcs-commadapter-loopback and opentcs-peripheralcommadapter-loopback, which are the reference implementations to copy when you write your own. The peripheral variant covers devices attached to a vehicle rather than the vehicle itself, such as a lift or a conveyor.@@P@@A useful detail is that the adapter is a separate module with a defined interface, so it can be developed and tested apart from the kernel, and the kernel does not need to change when a vehicle's protocol changes. The price is that a fleet with several vehicle types needs several adapters, each one a small protocol implementation you now maintain.

## The module map and the operator-facing tools

The repository is a multi-module Gradle build, and the module names describe the whole product rather than just a library.@@P@@opentcs-common holds shared types, opentcs-api-base and opentcs-api-injection are the public API surfaces, with the injection module pointing at the dependency injection approach used throughout. opentcs-impl-configuration-gestalt holds the configuration implementation, named after the Gestalt configuration library. The kernel sits at the centre with its two extension modules, and opentcs-kernelcontrolcenter is the control centre application.@@P@@Three more modules are user-facing rather than infrastructural. The operations desk, opentcs-operationsdesk, is the day-to-day operator view of the running system. The plant overview, split into opentcs-plantoverview-base and opentcs-plantoverview-common plus panels including a load generator panel, a resource allocation panel and default themes, is the visualisation of the plant and its state. The model editor, opentcs-modeleditor, is where the plant layout, vehicles and transport orders are defined.@@P@@The documentation is its own module, opentcs-documentation, and the README says the user's guide, the developer's guide and the API documentation are included in the binary distribution and can also be read online. The project also publishes a changelog, a CHANGELOG.adoc at the root, with the release notes kept in the documentation module.

## Building it and finding your way in

There is no installation section in the README, and the project instead points you at three documents: the user's guide, the developer's guide and the API documentation. That is a deliberate choice for a platform of this size, and it means the realistic first step is reading the user's guide rather than running an installer.@@P@@The build is a Gradle build, and the repository root carries the usual Gradle wrapper files, gradlew and gradlew.bat, alongside build.gradle, settings.gradle and gradle.properties, plus a gradle directory for the wrapper configuration. Building therefore means using the wrapper rather than a system Gradle installation, which keeps the build consistent across developer machines and CI. The presence of a .gitlab-ci.yml and a .gitlab directory alongside the .github directory shows the project runs pipelines on both GitHub and GitLab, and an .idea directory is committed for IntelliJ users. lombok.config is present as well, so the source uses Lombok and the annotation processing has to be enabled in your IDE.@@P@@The build outputs are the separate applications, the control centre, the operations desk, the plant overview and the model editor, and the binary distribution that the README mentions bundles the documentation alongside them. For a Java team, the practical shape of adoption is running the kernel as a service, pointing the operations desk at it, and connecting a vehicle adapter per vehicle type.

## Licensing, governance and where openTCS is the wrong tool

The licensing is a multi-licence arrangement, and the README is refreshingly honest about why. It says that keeping the section up to date is challenging, and gives a summary as of November 2024. All original source code is under MIT. All original assets, including the documentation, are under CC-BY-4.0. Some configuration and data files are under CC0-1.0, and some third-party assets are under Apache-2.0 or the SIL Open Font License. For anything more precise, the README points at the individual files and the REUSE.toml files.@@P@@That combination is friendly to commercial use in the way that matters. MIT for the code means you can vendor it into a proprietary product without publishing anything, CC-BY-4.0 on the documentation means you can republish the manuals with attribution, and CC0 on the data files removes attribution questions entirely. The files to check are the ones carrying third-party assets. The project also adopts the Contributor Covenant 2.1, with the code of conduct in the root.@@P@@The wrong-tool cases are clear. openTCS is built for fleets, so a single robot that navigates a fixed route needs none of this and would be better served by the vehicle's own controller. It is also the wrong answer for a fleet that already runs a vendor-supplied control system, because the whole point is to own the traffic logic, and a shop that has bought a complete control package has already paid for that logic.@@P@@The third wrong-tool case is the vehicle protocol. If your vehicles speak something other than VDA5050, you are signing up to write and maintain a communication adapter, and for a one-off installation that cost can exceed the value of the traffic management you gain. The honest way to evaluate the project is to price the adapter work, not the platform.

## Conclusion

openTCS suits integrators and research groups building a multi-vehicle intralogistics or production transport system where the traffic logic matters more than the vehicle hardware, and who can commit to writing a communication adapter for a non-VDA5050 vehicle. It is the wrong tool for a single robot, and for fleets that already run a vendor control system. Verify first that Java 21 is available on your build and runtime machines, that your vehicles speak VDA5050 or that you can write an adapter, and that the licence split between MIT source, CC-BY documentation and CC0 data files fits your distribution plans.

## FAQ

### What is openTCS?

openTCS, the open Transportation Control System, is a free platform for controlling fleets of automated guided vehicles and mobile robots. It provides the routing, dispatching and scheduling needed to run an AGV system with more than one vehicle, and is maintained by the openTCS team at Fraunhofer IML.

### Does openTCS support VDA5050 vehicles?

Yes. The README states that vehicles supporting VDA5050 can be integrated without additional programming, and the repository contains a dedicated opentcs-commadapter-vda5050 module for that protocol.

### What do I have to build to connect a vehicle openTCS does not know?

A vehicle driver, called a communication adapter in openTCS speak, that translates between the abstract interface of the openTCS kernel and the communication protocol your vehicle understands. The loopback adapters in the repository serve as reference implementations.

### What are the system requirements for openTCS?

The software runs on the Java platform version 21, with the Adoptium distribution recommended, and the README states that all libraries needed to compile or use it are freely available. The build is a Gradle build with the wrapper included in the repository.

### Under which licences is openTCS released?

Multiple. Original source code is MIT, original assets including the documentation are CC-BY-4.0, some configuration and data files are CC0-1.0, and some third-party assets are Apache-2.0 or OFL-1.1. The README points at the individual files and the REUSE.toml files for details.

## Sources

- [Issues](https://github.com/openTCS/opentcs/issues)
- [openTCS/opentcs on GitHub](https://github.com/openTCS/opentcs)
- [Project website](https://www.opentcs.org/)
- [README](https://github.com/openTCS/opentcs/blob/master/README.md)
- [Releases](https://github.com/openTCS/opentcs/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/opentcs-opentcs