sap apo 生产排程软件的架构和设计分析

sap apo 生产排程软件的架构和设计分析

1 apo 的算法

  sap apo的算法分两大类

  一类使用的是ilog公司的cplex 运筹学库，主要用于apo 的网络设计 snp 和vrp模块，snp 模块用的是整形规划的分支定界的算法,网络设计 用的是线性规划的算法

  另一类是pp/ds 生产排程的优化器，sap 公司自己写的，使用了并行遗传算法 和 规则算法

  ilog公司也有自己的生产排程引擎，基本上没有任何实用价值

  运筹学在优化领域有着广泛的应用，但它不适用与生产排程领域，对几十万上百万个生产工序节点建立数学计算模型是不可能，因此，规则法和并行遗传算法成了解决生产排程问题的两种具有实用价值的算法

  规则算法的问题是不能优化，而且对生产计划调整的支持也不好，不是不能调整，但一调整就乱，排出来的计划在执行的过程中一有变动，调整，插单，就全乱了，如果企业的实际生产不能和计划精确吻和，使用基于规则法的软件几个月后就用不下去了

  并行遗传算法是现在公认的解决生产排程问题的最好算法，它适用于任何复杂的生产排程问题，国内的isuperaps也提供了基于并行遗传算法的算法实现

 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++语言来开发