sap apo 軟件的架構和設計分析
1 apo 的算法
sap apo的算法分兩大類
一類使用的是ilog公司的cplex 運籌學庫，主要用於apo 的網絡設計 snp 和vrp模塊，snp 模塊用的是整形規劃的分支定界的算法,網絡設計 用的是線性規劃的算法
另一類是pp/ds 生產排程的優化器，sap 公司自己寫的，使用了遺傳算法 和 規則算法
ilog公司也有自己的生產排程引擎，基本上沒有任何實用價值
運籌學在優化領域有着廣泛的應用，但它不適用與生產排程領域，對幾十萬上百萬個生產工序節點建立數學計算模型是不可能，因此，規則法和遺傳算法成了解決生產排程問題的兩種具有實用價值的算法
規則算法的問題是不能優化，而且對生產計劃調整的支持也不好，不是不能調整，但一調整就亂，排出來的計劃在執行的過程中一有變動，調整，插單，就全亂了，如果企業的實際生產不能和計劃精確吻和，使用基於規則法的軟件幾個月後就用不下去了
遺傳算法是現在公認的解決生產排程問題的最好算法，它適用於任何複雜的生產排程問題
2 內存數據庫livecache
aps 軟件運行中，最佔用時間的是把數據從物理數據庫中提取出來，轉換成aps 軟件的數據結構，一但這種轉換完成，計算是非常快的，100萬個工序節點也就一秒種，但提取和轉換的過程可能需要幾小時，因此，使用內存數據庫是任何一個aps軟件的必然選擇
內存數據庫在第一次啓動時和物理數據庫初始化複製表數據，這個時間會很長，但以後只保持和物理數據庫的數據同步，不用再大批量複製數據了，排程時，就可以直接提取內存數據庫的紀錄進行轉換，因此極大的提高了速度
livecache 就是apo 使用的內存數據庫，在apo 的使用中，很大的一部分工作就是維護和優化livecache,當然了，在64位操作系統上，內存不在是短缺資源，livecache的管理工作也容易很多
3 apo 在實施中的難題
下面是一個企業說的實際情況
企業每天或過幾天就會接到訂單，有些是大客戶的緊急訂單，必須安排下去，簡單的生產排程和插單是不能滿足企業的要求的，必須是合理的插單，也就是不能插下去讓車間無法生產，也就是說某些時間段是不能插單的，常見的要求
1 不能在同一零件的生產空閒時間段插入另一個零件的生產，也涉及到要換模具，調整機器，是不可能的
2 同一零件如果特性值不同，比如顏色 用料等不同，也不能插進去，同樣涉及到要調機器
3 另外，如果是大客戶的緊急訂單，後面的生產計劃都要調整，要先完成緊急訂單
4 結果能優化，能讓排出來的生產計劃誤期的訂單數最少
插單不能亂插，不然會無法生產不能讓車間a生產100個，然後插入b生產10個，再a生產200個，而應該就是a生產300個，中間即使有空閒也不能插入b件的生產
除了插單，生產排程計劃的生成也有一些要求，比如支持並行工序 模具工人人數這些約束 ，我們的模具數量是有限的，也就是說有時候這個生產線有時間，但模具被其他生產線生產佔用了，這個生產線這個時間段就不能安排生產，另外我們很多零件好幾條生產線都能生產，要求能在這幾條生產線裏選擇一個最好的生產線（我們有選擇原則的）安排下去，要把特性值相同的零件安排在一起生產，不然切換時間會很長
apo可以實現簡單的插單和調整排程生產計劃，但是它插單只是找個空閒時間段安排下去，根本不考慮這樣插下去後能不能實際安排生產。它也沒有優化的功能，比如我們最需要的要求產生的生產排程計劃誤期訂單最少的功能，至少是大客戶的訂單不能誤期，也就是大客戶的訂單來了後，後面的生產排程計劃都要調整，要優先完成大客戶的訂單
4 apo 的算法定製
通過複雜的參數配置還是按客戶的排程思路定製,是apo 實施中必然要遇到的問題
另一個問題是，如果決定按客戶的排程思路進行定製，該怎麼在apo 的框架內去實現
定製算法其實就是重寫算法，因爲sap 不會公佈它的算法代碼，但apo 還是爲定製算法提供了很多支持，比如數據的讀寫接口，內存數據庫的調用接口，和業務應用編程接口bapi
apo自己的優化器都是c++編寫的，因此定製算法庫也應該使用c++語言來開發