计算机辅助制造中BOM的优化方案

作者：

欢迎访问e展厅 展厅 3 PDM/PLM/CAPP展厅 图文档管理系统, CAPP... 1 引言 在制造企业中，物料清单BOM（Bill of Material）表达了产品的配置关系，即一个产品包含了零部件的种类和数量以及它们之间的装配关系，它是联系销售系统、采购系统、制造系统、库存系统和财务系统的信息纽带。 各个环节需要面向不同部门的BOM，如销售系统中的发货需要客户BOM（Custom BOM）来维护客户订购的产品目录，即具体产品规格的明细表。 由于客户的个性化要求越来越高，要求产品类型不断推陈出新，设计BOM（Design BOM）能够帮助设计师迅速选择物料来设计出符合客户需求的产品。同样，工艺师也需要工艺BOM（Process Plan BOM）来选择加工工艺和制定生产计划。 采购系统根据PBOM 和库存水平制定采购BOM（Sourcing BOM），进行物料的采购工作，而财务系统根据以上所有BOM 表来进行成本的预算、核算工作。 为了减少各个环节中BOM 表的改变对整个系统的影响，BOM 表的设计要实现灵活的单级反查、多级反查和动态、静态调整等功能。 因此，BOM 是企业管理系统中的基础，它几乎与企业中的所有职能部门都有关系。 然而，在计算机辅助制造的信息系统中，BOM 分解是一项非常耗时耗力的工作。 尤其对大型设备的BOM 分解，运算时间之长也令人难以忍受。 2 BOM 展开和反查 物料清单BOM 列出构成产品或装配件的所有零件、部件以及它们之间的装配关系和数量关系，企业 各个部门都要依据统一的物料清单进行工作，许多业务涉及到BOM 运算，譬如零件生产计划、原材料毛需求计划、缺件查询、总装发料、成本核算、生产统计等，BOM 的主要运算是展开或反查。 BOM 展开的目的是得到产品或部件的下级组成成分及其数量；反查则与之相反，它追踪零部件在哪些上级装配件中使用及使用情况。 2．1 BOM 展开包括 2．1．1 单级展开 按水平层次顺序分拆一个装配件成为它的直接组成部分，如图1 所示。 单级展开被用于的业务有，装配车间和仓库计算某个装配件的组成零部件，统计部门对某个装配件的成本计算等。 2．1．2 层次展开 本文简称BOM 分解，即按产品、部件的装配形态，自上而下、从左到右地分解装配件，直到最底层的物料为止，如图2 所示。 它可用于总装配计划、部件装配计划和缺件查询，也可用于质量追溯等。 2．1．3 综合展开 按产品汇总列出每个物料的总需要量清单，如图2 所示。 可用于决定零件、毛坯和原材料的毛需求计划、部装和总装的成批发料、部件或产品的材料、工时和成本统计等。 2．2 BOM 反查 如图3 所示，包括： 2．2．1 单级反查 按使用顺序查询一给定位置物料在其父项物料中的使用情况。 利用它可以帮助生产计划人员了解加零件或原材料短缺可能引起的直接问题等。 2．2．2 层次反查 级联追踪一给定位置物料的父项物料，直至顶层最终产品中的使用情况。 它可用来确定某个物料的短缺或报废对其上层物料产生的一系列影响，譬如如果某个原材料短缺，那么零件不能按时加工，导致部件装配不能按时完成，最终整台产品交货日期推迟。 2．2．3 综合反查 反查给定物料在其所有父项物料中的使用情况。 它可用来统计物料材料或工时的改变对整台产品的影响，确定由于物料质量上的问题而受影响的其它所有物料。 2．3 BOM 运算 BOM运算中使用的字段并不多，主要是记录ID、物料码、层次码、属数量和总数量。 物料码是计算机识别物料的标志，它必须具有全厂唯一性。 层次码反映了某项物料相对与指定项目的层次。 在BOM的运算中，运算量最大的是BOM分解，它被广泛用于生产计划、调度、装配、统计等许多生产业务，运算频繁。目前，许多BOM分解的方案工作量大，数据容易出错，分解速度慢，往往成为工作的瓶颈。 这主要是以下原因所致： 2．3．1 系统集成度不高 BOM 在各个部门之间无法共享。 譬如设计部门的BOM 发生改变后，难以迅速反映到生产部门，只能通过手工方式对BOM 进行转移，工作量大且容易出错。 2．3．2 关系数据库与BOM 在数据模型上的本质差异 现在企业一般采用关系数据库构成企业的数据库系统，BOM 的本质是树型的，节点数据呈层次型分布，虽然可用关系表来存放数据，但是关系数据库本质上不按照层次模型组织和处理数据，没有直接描述节点之间的指向或所属关系，即便对简单的层次型数据处理也要做耗时的表连接运算，效率很低。 另外，关系数据库在操作BOM 数据时也无法进行一些必要的内部逻辑检查，譬如一个节点的父节点的ID 如果是它本身却也能插入这个节点，但这明显是不对的。 或者一个节点向上反查时又回到了自己本身，形成一个闭环而无法进行后续处理。 而对于BOM 来说，应能达到100%的准确性，所以当BOM 数据改变时，只能通过繁琐的程序进行数据逻辑检查。 2．3．3 服务器计算任务过重 企业网络还有许多客户机使用哑终端，没有智能，所有运算都要依赖于服务器，BOM 分解的运算量又大，所以服务器资源很容易形成运算瓶颈。 当企业并发任务过多时，等待时间过长。 2．3．4 模块设计不够灵活 BOM 的分解用到的关键输入数据是顶层物料和层次码。 在对一个产品进行分解时，顶层物料是产品，当进行部装领料时，顶层物料是指定的部件；层次码是相对顶层物料的，随着顶层物料的改变也会随之改变，只对于某次运算是有效的。 所以，对于不同的业务功能BOM 分解的具体实现也不同，造成BOM 分解模块的重用性和维护性差，给程序的设计和日后的维护工作带来诸多的不便。 3 BOM 分解的分布式计算方案 随着计算机硬件和软件的发展，企业分布式计算已经非常普及。 采用分布式计算，可以充分利用企业内的所有计算资源，对BOM 分解进行优化设计，解决运算瓶颈。 本文提出一个可以大幅提高运算效率并且稳定的方案。 图4 显示的是BOM 分解方案的优化模型，它从检索、传输和运算方面，对数据库索引、大表和存储过程进行了优化，对分布式计算、层次数据支持、接点次序以及错误检查都进行了改善。 它不是仅仅针对某个对象（譬如服务器）的优化，也非简单地拼凑优化对象，而是从系统的观点出发，多方面考虑了服务器、客户机和软件算法的各自的特点，加以改进并对它们进行有机的组合，最后达到BOM 分解综合性能的优化。 分布运算的数据处理流程大致如下：分解时，客户机生产管理系统调用本地BOM 分解公共函数，函数调用SQL 语句或服务器存储过程，服务器执行SQL 语句或存储过程，并将处理后的结果返回客户机，客户机再根据自己的业务需要灵活地对返回的结果进行进一步地处理，最后完成整个业务。 BOM 分解流程如图5 所示。 采用本方案进行BOM 分解，有以下优点： 3．1 优先利用服务器 将一些固定的而且使用频繁的运算作成服务器端执行的存储过程，客户端进行远端调用，服务器向客户机传回运算后的结果。 这不但可以充分利用服务端的高速处理优势，而且减少了网络数据传输，也带来维护上的方便——有更好的算法或业务规则改变时只需更改服务器上的存储过程。 3．2 必要时利用客户机 Oracle 数据库服务器使用的是扩充过的SQL 语言PL/SQL，在灵活性方面不如强大的客户机开发工具（如Powerbuilder），对一些需要有较大灵活性的运算，可将服务器要处理的数据传到客户机上处理，满足运算的灵活性需要。 客户机一般由微机担任，处理的数据始终存放在内存中，所以运算速度并不慢。 这样不但减轻了服务器的负荷，还可以减少运算过程中与服务器的数据传输，降低网络的传输流量。 3．3 尽可能多利用ORACLE 数据库系统提供的功能 譬如ORACLE 对层次型数据提供了一些便利的操作和伪列，因为这些操作被优化过，伪列也是针对层次型数据的，所以在方案设计时候优先考虑利用服务器对层次型数据提供的支持。 3．4 改善数据的检索性能 对于BOM 表的检索，可根据实际使用情况在SQL 语句出现频率高的条件字段上建立索引，以加快检索速度。 如果BOM 表中数据记录太多而影响I/O 性能时可以考虑是否分割大表，或将大表分布在不同的硬盘上以提高I/O 速度。 3．5 通过ORACLE 性能的调整来提高数据处理的能力 如通过增加CPU 和内存的数量提高服务器性能，通过设置更大的cache 区大小来提高数据读写速度，通过数据的经常备份来使系统轻载，通过空闲时段的数据整理来提高系统的检索效率。 3．6 优化BOM 的分解算法 首先需要在数据结构上为算法做相应的设计，数据结构为算法服务，算法操纵数据。 BOM 分解计算策略分递归和非递归，如果关系表中存放的数据前后之间并没有一定的关系，就只能每次查找某个节点的父节点或子节点时要搜寻整张表，直到查到根节点，这种算法只能采取递归或多重循环实现，递归要频繁地调用函数，入栈出栈非常耗时。 即便稍做改进，采用多重循环，当记录较多时计算复杂性会呈指数增长，速度同样令人难以忍受。 如果先按照一定的遍历规则将无序的节点有序化，之后对有序化后的记录顺序处理一遍就可以完成分解运算。 在分解前，对数据进行前置处理以便减少无为的运算。 譬如，对数据进行逻辑检查，确保数据没有逻辑错误后；将运算结果存放在服务器的临时表中，在运算前先查看临时表中是否已有所要的运算结果，如果有就不必再运算。 确定和调整缺陷预防策略;辅助质量成本管理和优化。 3．7 通过三层架构的设计，使BOM表分解任务部署到业务逻辑层 利用C＋＋等善于处理层次型数据结构的语言来实现BOM的展开和反查，因为减少了与数据库的交互，效率将得到明显提高。 4 结束语 根据以上方案，我们成功解决了杭州制氧集团透平分厂的BOM 分解问题，大大提高了生产效率，使生产计划能够得到及时的制定和调整， 系统运行可靠，性能稳定。 因为该问题在制造业信息化中普遍存在，不同的网络环境和计算量使问题解决的方法有所差异，本方案提供了可供参考的经验和可行的优化策略。(end)

文章内容仅供参考 (投稿) (如果您是本文作者，请点击此处) (4/19/2006)