本文來談一談OpenTCS的調度問題。
OpenTCS默認的算法是基於"前饋鎖路"的方式進行交通管制的。
所謂的“前饋鎖路”，意思是當某輛車需要運動時，在運動之前會將MovementCommand轉換成一種交通管制資源向系統中註冊。只有當該資源被系統接受時，車輛纔會運動，大致的邏輯如下所示：
OpenTCS的這種默認交通管制策略其實比較簡單，也容易理解，那麼這種方式是否在實際項目中就可以使用了呢？答案是分情況，寬闊的場地可以充分規劃雙行線的場景一般沒有什麼問題，但是對於一些場地受限制的場景，比如幾乎只能使用單行線的工作場地，這種算法依舊是無法解決死鎖問題的。所以下面主要講講這種情況下的死鎖問題。
舉個栗子，假如存在下面這個地圖：
系統中存在兩輛車，初始位置分別停靠在12點和13點。這是一個很簡單的地圖，正常運行時也不會有多大問題，但是這個地圖有個特點，那就是路段只允許一臺車通過。如果使用OpenTCS默認的算法，就會存在死鎖問題，比如遇到下面的情況：
當某輛車在Location-0001作業完後，需要回到停靠爲12，此時系統規劃了一條通往12位的路徑，但是同時有一個訂單要求另一輛車從13點通往Location-0001，系統又會生成一條路徑從13點通往Location-0001。
此時死鎖就極有可能發生，如下所示：
對於上述死鎖問題的改進辦法個人認爲有下面兩種：
1、錯開訂單的下發。
2、改進調度資源分配算法，將雙向路徑考慮到資源分配的過程當中(改進方法可關注後面的文章)。
當然還存在其他的死鎖問題，在項目應用時需要特別注意。
、