This article briefly introduces OpenTCS as an open-source fleet management system and focuses on its positioning and suitable use cases, based on practical integration experience, to help engineers assess whether it fits their needs.
車隊管理系統 (Fleet Management System) 是調度多台AGV(AMR)時所需的必要系統，其功能主要包括整合上位系統、任務管理、交通管理、充電策略等等，目的是讓車輛的運行順暢和符合上位系統(MES or WCS)的期待，這篇文章將介紹筆者接觸到的開源解決方案 OpenTCS 是一個什麼樣的車隊系統，又適合哪些用戶來使用，協助工程師評估導入的可行性，不會包含詳細的功能說明和操作步驟。
目錄
中文內容
OpenTCS 簡介
OpenTCS 是由德國公司 Fraunhofer IML 維護的開源專案，採用寬鬆友善的 MIT 授權，該車隊系統的Scope包含了一般對車隊系統的認知的功能，因爲供應商中立的特性，可以自行整合任意協定的車輛，這也意味着官方沒有爲了特定廠商開發協定的Adapter，需要自己動手開發對應的Adapter，唯一支援的協定，也是開源的AGV控制協定 VDA5050，github上有專門的 Repo 維護 VDA5050 Adapter，對於電梯或自動門等設備的整合，也可以開發週邊設備的Adapter自行整合，可以做到確保設備回到成功才讓車子拿到路徑資源允許通過。
其使用的程式語言爲 java，支援跨平臺使用，官方提供了 3 個桌面程式和1個控制台程式，分別是
- Model Editor : 地圖編輯器，用來編輯地圖layout以及車輛資訊
- Operations Desk : 觀看車輛、任務、路徑資源的即時狀態，可以進行派車、設定車輛可用性等
- Kernel Control Center : 車輛和週邊設備的控制管理，可以設定車輛的 Adapter 類型、停用啓用、週邊設備控制，可以看一些 Kernel Watchdog 的訊息
- Kernel : 車隊的主程式，沒有任何 UI，會將運行狀況以文字顯示在控制台界面上，前三者操作時，都是對 Kernel 進行連線後才能動作
整體而言，應用程式的 UI 非常工程師，算是堪用狀態，一些簡單的操作也需要做很多動作，屬於簡單直接沒有 UX 的 UI，更新方面，目前 OpenTCS 算是活躍的專案，約1-2個月就會發佈更新，持續修復問題和提供新功能，爲了方便描述，以下會將 OpenTCS 簡稱爲 TCS。
重點功能介紹
地圖
TCS的地圖屬於拓撲式，由點和線組成，比較特別的是兩點之間來回會算成2條線，而不是1條線，地圖上可以定義的元素如下
- Point：定義坐標、角度、類型
- Path：定義路線，包含開始與結束的Point、最高速度、是否鎖定
- Location Type：站點類型，供站點參照，定義可執行的”操作“，像是對接、充電等，也可以定義可執行的設備”操作“，像是開門”關門等
- Location：站點，關聯到特定的Point，作爲派車的目的地，也可以是設備的觸發點，會跟Path關聯，像是走到這條路就觸發開門，開門完成後才會把命令發給車子
- Block：資源的集合，所謂的資源指的是前面的Point、Path、Location，不同類型有不同作用，像是僅允許一臺車或是僅允許相同入口，不符合條件時，車輛會在外面等待，直到可以爲止
- Vehicle：定義車輛屬性，有名稱、最高速度、電量門檻、尺寸、允許接受的任務類型（一對多）、整合度，其中整合度可以決定車子是否占用資源、允許接收任務
爲了可以整合各種車輛和客製化邏輯，以上各元素都支援自定義屬性，這算是TCS的特色，TCS自己的屬性會用 tcs: 為前綴，整合 VDA5050 時，adapter 也會讀取 vda5050: 開頭的屬性，保留最大的彈性
任務管理
TCS 的搬運任務稱爲 TransportOrder，是上位派車時的最小單位，可包含多個目的地，每個目的地就像一個子任務，稱爲DriveOrder，TransportOrder 可以指定
- 類型：對應 vehicle 的任務類型，可以做到不同類型的車接收各自類型的任務
- 期限時間：用來當成排序得參考
- 指定車輛：是否指定特定車輛執行
- 自動取消：主要用於回待命區或充電的 Order，可自動取消並接受新的 Order 節省時間
- 依賴：可設定A和B任務都完成後才執行此任務，TCS 會依照依賴順序執行 Order
- 客製化屬性：這邊定義的屬性都可以在 Adapter 內被讀取到，用來實現客製化的功能，以 VDA5050 Adapter 爲例，可以定義在目的地要執行的 action
任務的排序和每個任務挑選車子的條件可在config中進行態調各條件的優先順序，可以做到回頭車、Order期限快到時優先執行等較複雜的任務管理
路徑搜尋與成本
TCS內建 Dijkstra 算法找尋成本最低的路徑，成本則可以在 config 中多選，像是距離、Point數量、時間、群組、尺寸，其中群組是可以在 Path 和 Vehicle 定義屬性，讓相同群組的車使用對應的成本值，可以做到特定路讓特定車優先，尺寸則是在 Point 限定允許通過的大小，若 Vehicle 定義的大小超過則成本無限大，不允許通過，路徑一旦算出來後，就不會再改變了，基本上Path的鎖定沒有變更的話，算幾次都是一樣的結果
交通管理
有資源管理的概念，每個資源同時只能被一台車持有，正常狀況下，每台車會持有所在的 Point，有任務路徑時，會持有後續 N 段 Path 和 Point，如果路徑有交錯，先拿先贏，其他車只能等待釋出後再取得。
有些時候兩台車算出來的路徑會有衝突，例如都在同一條雙向道上，兩台車都各拿1個點，就會造成黑羊白羊過橋問題卡住，這時候可以設定 Block 來限定特定區域只能一台車來避免問題，但 Block 是把雙面刃，過度設置也會造成交通癱瘓
另外針對設備的部分，可以在走到特定路線時，對特定的設備 Adapter 發起 Open 的命令，等到設備確實回報成功，才會將行走的命令發給車子，並且繼續往後占有路權
待命區
Point 的類型可以選擇待命區，然後 config 檔設定閒置時自動回待命區，還可以設置待命區的優先順序，或是特定車輛停在特定待命區，更進階的還可以設定當優先權高的待命區空出時，重新把低優先權的車派過去停。
充電策略
每台車可以設定幾個門檻
- 低 critical energy level 於門檻時，不接任務且前往充電
- 低 good energy level 於門檻時，閒置時會去充電，但一有任務就會中斷去執行任務
- 高 full (sufficiently) recharged energy level 於門檻時，停止充電，回到待命區
也可以設定每輛車優先或特定的充電站，但僅此而已
模擬車
TCS 有提供模擬車輛，可以接收任務模擬行走，但是真實度有限，行走部分並不會參考速度，而是一個點一個點跳躍，可以用來測試地圖的可運行性，另外有支援耗電跟充電功能，可以測試充電策略
整合性
針對外部系統整合部分，有提供Restful Web API，跟 Swagger 可以了解格式，但是沒有 event trigger 的方法，只能不斷輪詢，頂多有一個 long polling 的API可以接收所有類型的 event，使用過後還是直接輪詢特定資訊的 API 比較方便
對於車子的部分，需要自行開發Adapter，這部分可以參考模擬車的專案進行修改，將 TCS 這邊定義的 command 發給車子，並把車子回傳的狀態，對應到TCS的車輛狀態，像是電量、是否有貨、閒置還是執行中等等，就可以控制車子
對於設備的部分，也是有開放Adapter的開發彈性，看你是要整合電梯還是自動門等，有明確的協定就可以完成
使用心得
各功能評估
以下對針對各功能評估對於一般使用情境是否足夠，尚缺哪些必要機制
✅：滿足所需
🆖：堪用但不足
❌：不滿足需求
| 功能名稱 | 評價 | 評論 |
| 工具軟體 | 🆖 | Model Editor 操作有大量待優化空間，尤其是地圖設定自定義屬性的操作步驟過多，且沒有檢查機制，很容易漏東漏西 Operations Desk 可派簡易的循環任務，但不支援派含有自定義屬性的任務，只能自己打 API，另外可以看每台車的路權，不過想要看交互關係（A車卡B車、B車卡C車）就只能自己分析了 Kernel Control Center 操作部分較少，算是堪用，但要看問題，內建的 watchdog 資訊還是太少 以上工具還有一個缺點，就是一定要執行程式，沒有提供網頁界面快速瀏覽，也沒有提供權限功能，一定程度上很難給非維護單位使用，需要自行開發好用的 UI Kernel 有些機制不方便，會影響維運，像是上傳地圖會中斷並清空所有任務，重啓也不會記憶先前的任務，也沒有歷史資訊可供查詢，所以要上傳地圖或是升版的話，就必須取消所有任務，事後再重派 |
| 地圖 | ✅ | 基礎屬性已涵蓋大部份功能，且支援自定義屬性，有高度擴充性 |
| 任務管理 | ✅ | 有支援優先權概念和距離概念，也可以設定車子對應不同任務類型的優先權，算是非常完整足夠 針對一連串任務有 sequence 功能支援綁定同一台車，避免車輛在任務中間空檔接收其他任務 |
| 路徑搜尋與成本 | 🆖 | 有基礎的功能可用，但成本沒辦法考慮旋轉次數，會以純距離或是時間來看，有些人覺得很繞的路在TCS看來成本是一樣的，需要再自行擴充需要的功能 如果現場想要特別繞遠路，原生雖有支援，但設定方式非常繁瑣和不好維護 |
| 交通管理 | ❌ | 這部分是真的不夠用，除非你的場域非常足夠，可以每條路都兩線道，只有簡單十字路口要交管，就可以勉強應付 Block 的維護很看人的經驗，尤其是考慮避障後，像是要轉彎的地方或是十字路口，或是兩條路某一段太接近，爲了避免兩車太近觸發避障，就要廣設 Block，漏設就等着現場反映問題 另外雖支援大車不能走小路，但沒有動態切換功能，像是有些路空車可以走，載貨體積變大不能走，目前是做不到的 不支援動態路徑，看起來會覺得很不聰明，只能等待後通過 |
| 待命區 | ✅ | 蠻完整的，可設定優先權甚至重新停到高優先權，可以依照不同情境設定 |
| 充電策略 | 🆖 | 只有門檻機制過於簡單，多車共用充電站時，沒辦法交換充電，除非一直有任務進來，才會剛好離開空出充電站，但還是沒辦法避免多車同時沒電的問題 |
| 模擬車 | 🆖 | 僅能驗證地圖和交管機制，缺乏速度模擬跟對接等待時間，沒辦法用來算精確的時間 |
| 整合性 | ✅ | WebAPI速度算快，幾十ms就會回傳，即使輪詢也足以負荷 如果想要 event 機制，就需要自行擴充，內部可以接收 event 再看要用什麼機制發出 |
期望與落差
雖然更新頻繁，但是看到新的功能時，不要太過興奮跟腦補，往往都只是提供最陽春的功能而已，舉個例子，某一版開始可以設定車子和點的長寬高，讓大車不能走小路，但僅此而已，占用路權時並不會用這個條件考慮，讓車身彼此不重疊，所以新功能務必試過後才能確定運作機制
適用客群
TCS 需要二次開發，沒辦法開箱即用，即使使用 VDA5050 協定的 Adapter，多多少少還是有一些邏輯需要客製修改，bug 也還是有，筆者本身也提報過一些 bug 給官方修改，所以適合原本已有做車子的廠商，或者是一開始就鎖定發展車隊系統的廠商
比起平地造山，還是可以省掉不少工，但就是要花點心思看懂TCS內部程式架構，TCS的架構算是設計的不錯，雖然功能較多切分的class非常多，抽象化得很徹底，但一旦釐清後，修改或替換的工相對少，日後也不難維護
English Version
Introduction to OpenTCS
OpenTCS is an open-source project maintained by Fraunhofer IML in Germany and released under the permissive MIT license.
The scope of OpenTCS covers the common functionality expected from a fleet management system. Due to its vendor-neutral design, it allows integration with vehicles using arbitrary protocols. However, this also means that OpenTCS does not provide protocol adapters tailored to specific vendors out of the box; users are expected to implement the required adapters themselves.
The only officially supported vehicle protocol is the open-source AGV control protocol VDA 5050. A dedicated GitHub repository is maintained for the VDA 5050 adapter.
For integrating equipment such as elevators or automatic doors, OpenTCS supports peripheral device adapters, which can be implemented to coordinate vehicle movement with external devices—for example, ensuring that a vehicle is granted path resources only after the device operation has completed successfully.
OpenTCS is implemented in Java and supports cross-platform usage. The official distribution includes three desktop applications and one console application:
- Model Editor:
A map editor used to define the layout, plant model, and vehicle information. - Operations Desk:
Provides real-time visibility into vehicle states, transport orders, and path resources. It also allows manual dispatching and configuration of vehicle availability. - Kernel Control Center:
Used for managing vehicles and peripheral devices, including adapter configuration, enabling or disabling components, and monitoring Kernel watchdog messages. - Kernel:
The core fleet management service. It has no graphical user interface and outputs runtime information as text in a console. All three desktop applications must connect to the Kernel in order to operate.
Overall, the user interface of OpenTCS is highly engineering-oriented and functional but minimal. Even simple operations often require multiple steps, reflecting a straightforward design with little emphasis on user experience.
In terms of maintenance and development activity, OpenTCS is an active project, with releases approximately every one to two months, continuously addressing issues and introducing new features.
For convenience, OpenTCS will be referred to as TCS in the following sections.Introduction to OpenTCS
OpenTCS is an open-source project maintained by Fraunhofer IML in Germany and released under the permissive MIT license.
The scope of OpenTCS covers the common functionality expected from a fleet management system. Due to its vendor-neutral design, it allows integration with vehicles using arbitrary protocols. However, this also means that OpenTCS does not provide protocol adapters tailored to specific vendors out of the box; users are expected to implement the required adapters themselves.
The only officially supported vehicle protocol is the open-source AGV control protocol VDA 5050. A dedicated GitHub repository is maintained for the VDA 5050 adapter.
For integrating equipment such as elevators or automatic doors, OpenTCS supports peripheral device adapters, which can be implemented to coordinate vehicle movement with external devices—for example, ensuring that a vehicle is granted path resources only after the device operation has completed successfully.
OpenTCS is implemented in Java and supports cross-platform usage. The official distribution includes three desktop applications and one console application:
- Model Editor:
A map editor used to define the layout, plant model, and vehicle information. - Operations Desk:
Provides real-time visibility into vehicle states, transport orders, and path resources. It also allows manual dispatching and configuration of vehicle availability. - Kernel Control Center:
Used for managing vehicles and peripheral devices, including adapter configuration, enabling or disabling components, and monitoring Kernel watchdog messages. - Kernel:
The core fleet management service. It has no graphical user interface and outputs runtime information as text in a console. All three desktop applications must connect to the Kernel in order to operate.
Overall, the user interface of OpenTCS is highly engineering-oriented and functional but minimal. Even simple operations often require multiple steps, reflecting a straightforward design with little emphasis on user experience.
In terms of maintenance and development activity, OpenTCS is an active project, with releases approximately every one to two months, continuously addressing issues and introducing new features.
For convenience, OpenTCS will be referred to as TCS in the following sections.
Key Features Overview
Map
The map model in TCS is topological, composed of points and paths. One notable characteristic is that bidirectional movement between two points is represented as two separate paths, rather than a single bidirectional path.
The following elements can be defined in the map:
- Point: Defines a coordinate, orientation, and point type.
- Path: Defines a route between two points, including the source and destination points, maximum allowed speed, and whether the path is locked.
- Location Type: Defines the type of a location and the set of executable operations associated with it, such as docking or charging. It can also define executable device operations, such as opening or closing a door.
- Location: Represents a destination associated with a specific point. Locations can be used as dispatch targets for transport orders or as trigger points for peripheral devices. Locations can be associated with paths—for example, reaching a specific path may trigger a door-opening operation, and only after the operation is completed will the command be sent to the vehicle.
- Block: Represents a collection of resources. Resources refer to points, paths, and locations. Different block types enforce different constraints, such as allowing only one vehicle at a time or restricting access to vehicles entering from the same direction. If the constraints are not satisfied, vehicles will wait outside the block until access is granted.
- Vehicle: Defines vehicle properties such as name, maximum speed, battery thresholds, physical dimensions, accepted transport order types (one-to-many), and integration level. The integration level determines whether the vehicle is allowed to allocate resources and receive transport orders.
To support integration with various vehicle types and custom logic, all of the above elements support custom properties, which is a key design feature of TCS.
Built-in OpenTCS properties use the tcs: prefix, while adapters—such as the VDA 5050 adapter—can read properties prefixed with vda5050:, preserving maximum flexibility for extensions and integrations.
Task Management
In TCS, a transport task is called a TransportOrder, which is the smallest unit submitted by higher-level systems for dispatching.
A TransportOrder may contain multiple destinations, where each destination acts as a sub-task referred to as a DriveOrder.
A TransportOrder can be configured with the following attributes:
- Type:
Corresponds to the task types supported by vehicles, allowing different vehicle types to accept only their respective task categories. - Deadline:
Used as a reference for task prioritization and sorting. - Intended Vehicle:
Specifies whether a particular vehicle is assigned to execute the order. - Dispensable:
Primarily used for orders such as returning to a parking area or charging.
These orders can be automatically canceled when a new order becomes available, reducing idle time. - Dependencies:
Allows defining prerequisite orders. For example, an order may only be executed after both Order A and Order B are completed.
TCS schedules and executes transport orders according to the defined dependency chain. - Custom Properties:
Properties defined here can be read by the vehicle adapter to implement custom behaviors.
For example, in the VDA 5050 adapter, actions to be executed at a destination can be defined via these properties.
Task prioritization and vehicle selection criteria are configurable via configuration files, where the priority of different factors can be adjusted.
This enables more advanced task management strategies, such as prioritizing return trips, or executing orders with approaching deadlines ahead of others.
Path Finding and Cost Calculation
TCS uses the built-in Dijkstra algorithm to find the lowest-cost path.
The cost function is configurable and can be composed of multiple factors, such as distance, number of points, travel time, group, and size.
The group factor can be defined as a property on both paths and vehicles, allowing vehicles within the same group to apply specific cost values. This makes it possible to prioritize certain routes for specific vehicles.
The size constraint is defined on points to restrict the maximum allowed vehicle size. If a vehicle’s defined size exceeds the allowed limit, the cost is treated as infinite, and the path becomes non-traversable.
Once a route is calculated, it remains unchanged. As long as path locks do not change, repeated calculations will yield the same result.
Traffic Management
TCS adopts a resource management model in which each resource can be held by only one vehicle at a time.
Under normal conditions, a vehicle holds the point it is currently occupying. When executing a transport order, it additionally reserves the next N segments of paths and points along its planned route.
When multiple routes intersect, resource allocation follows a first-come, first-served principle. Other vehicles must wait until the resources are released before proceeding.
In some cases, route conflicts may still occur. For example, when two vehicles plan routes along the same bidirectional path and each holds one point, a classic deadlock situation—similar to the “bridge crossing” problem—can arise.
To mitigate this, Blocks can be configured to restrict a specific area to a single vehicle at a time. However, blocks are a double-edged sword: excessive or overly coarse block definitions can significantly reduce throughput and even lead to traffic congestion.
For peripheral device integration, TCS allows issuing open or control commands to a specific device adapter when a vehicle reaches a designated path.
Only after the device reports successful completion will the movement command be sent to the vehicle, and the vehicle will continue reserving subsequent route resources.
Parking Areas
Points can be configured with a parking position type.
Through configuration files, vehicles can be set to automatically return to a parking position when they become idle.
Parking positions can be assigned priorities, or specific vehicles can be restricted to park at designated parking positions.
More advanced configurations allow vehicles parked at lower-priority positions to be reassigned and moved when a higher-priority parking position becomes available.
Charging Strategy
Each vehicle can be configured with multiple battery thresholds:
- Critical energy level: When the battery level falls below this threshold, the vehicle will stop accepting transport orders and proceed directly to charging.
- Good energy level: When the battery level is below this threshold, the vehicle will go charging while idle, but will interrupt charging and execute a transport order as soon as a new order is assigned.
- Full (sufficiently recharged) energy level: When the battery level reaches this threshold, charging stops and the vehicle returns to a parking position.
Vehicles can also be configured to prefer or restrict themselves to specific charging stations.
Beyond these options, the built-in charging strategy remains relatively simple.
Simulated Vehicles
TCS provides simulated vehicles that can receive orders and simulate movement. However, realism is limited: movement is discrete, point by point, without considering actual speed. It is mainly useful for testing map feasibility.
The simulation also supports battery consumption and charging, allowing you to test charging strategies in a controlled environment.
Integration Capabilities
For external system integration, OpenTCS provides a RESTful Web API, along with Swagger documentation for understanding request and response formats.
However, the API does not provide true event-based callbacks. Consumers must rely on continuous polling, with the only alternative being a long-polling API that delivers all event types in a single stream.
In practice, after experimenting with the long-polling approach, polling specific APIs for targeted information often turns out to be more practical and easier to manage.
For vehicle integration, a custom Communication Adapter must be implemented.
The built-in simulated vehicle adapter serves as a good reference and can be extended or modified. The adapter is responsible for translating OpenTCS commands into vehicle-specific control commands, and mapping vehicle feedback back into OpenTCS vehicle states, such as battery level, load status, idle or executing state, etc.
Once this mapping is in place, the vehicle can be fully controlled by TCS.
For peripheral devices, OpenTCS also provides flexible adapter extension points.
Whether integrating elevators, automatic doors, or other equipment, as long as a clear communication protocol exists, the integration can be implemented via a custom adapter.
Practical Evaluation
Feature Assessment
The following evaluates whether each major feature is sufficient for typical real-world use cases, and highlights areas where additional mechanisms are required:
- ✅ Meets requirements
- 🆖 Usable but insufficient
- ❌ Does not meet requirements
| 評價 | 評論 | |
| Tools & Software | 🆖 | Model Editor: The interface has significant room for optimization. Editing custom properties in maps requires too many steps and lacks validation, making it easy to miss configurations. Operations Desk: Supports simple cyclical task dispatching, but does not support tasks with custom properties—these must be submitted via API. It allows viewing each vehicle’s reserved resources, but analyzing interactions (e.g., Vehicle A blocking B, Vehicle B blocking C) must be done manually. Kernel Control Center: Limited functionality; usable but minimal. The built-in watchdog provides insufficient information for debugging. General tools limitation: All tools require running the programs; there is no web-based interface for quick overview, nor role-based access control. This makes it difficult for non-maintenance personnel to use without developing a custom UI. Kernel: Some mechanisms complicate operations and maintenance. Uploading a new map interrupts and clears all existing tasks, and restarting does not retain prior tasks. No historical data is available. Updating maps or upgrading versions requires canceling all tasks and redispatching afterward. |
| Map | ✅ | Basic properties cover most needs and support custom attributes, offering high extensibility. |
| Task Management | ✅ | Supports priority and distance concepts. Vehicle order type mapping for prioritization is available, making it very complete. Supports sequencing to bind multiple orders to the same vehicle, preventing idle gaps during task execution. |
| Path Finding & Cost | 🆖 | Basic functionality is available, but cost calculation does not account for rotation counts; it considers only distance or time. Some routes that feel circuitous may appear equal in cost in TCS. Additional functionality may require custom extension. Native support exists for intentionally choosing longer routes, but configuration is cumbersome and difficult to maintain. |
| Traffic Management | ❌ | Limited for complex environments. Only works reasonably in spacious areas where paths can accommodate two lanes, and only simple intersections require traffic management. Block maintenance is highly experience-dependent. Considering collision avoidance, corners, intersections, or closely spaced paths may require extensive Block setup; missing blocks can lead to on-site issues. Supports restricting large vehicles from small paths, but no dynamic switching. For example, empty vehicles can use certain paths, but vehicles carrying cargo exceeding size limits cannot dynamically switch—this is not supported. Dynamic rerouting is unsupported; vehicles must wait for resource release, which may appear unintelligent in practice. |
| Parking Areas | ✅ | Quite complete. Supports priorities and reassigning vehicles to higher-priority positions. Configurable for various scenarios. |
| Charging Strategy | 🆖 | Only uses a simple threshold mechanism. When multiple vehicles share a charging station, there is no active handover. Vehicles may free the station only if new tasks arrive, but cannot avoid situations where multiple vehicles simultaneously run out of battery. |
| Simulated Vehicles | 🆖 | Useful for validating maps and traffic management logic. Lacks speed simulation and docking wait time, so it cannot provide accurate timing estimates. |
| Integration | ✅ | Web API is fast (tens of milliseconds), and even polling can handle the load. Event-driven mechanisms require custom development. TCS can internally receive events, but you must implement your own mechanism to trigger them externally. |
Expectations vs Reality
Although OpenTCS is updated frequently, new features should not be overhyped or assumed to be fully mature. Often, they provide only the most basic functionality.
For example, a recent version added the ability to define vehicle and point dimensions to prevent large vehicles from using small paths. However, this feature does not affect resource occupation calculations—vehicles may still overlap in space. Therefore, new features must always be tested in practice to understand their actual behavior and limitations.
Target Users
TCS requires custom development and cannot be used straight out of the box. Even when using a VDA5050-compliant adapter, some logic still needs to be customized, and bugs are still present—the author has personally reported several to the official maintainers.
TCS is most suitable for companies that already operate vehicles or those that are committed to developing a fleet management system from the start.
Compared to building everything from scratch, TCS can save considerable effort. However, it requires time and focus to understand the internal architecture. The system is well-designed: although there are many classes and extensive abstraction, once the architecture is understood, modifications or replacements require minimal effort, and maintenance is straightforward in the long term.
木澤的研發腦 