面向服务架构的制造运作系统模型

[顽石]

 面向服务架构的制造运作系统模型

Thursday, May 22, 2008

4:35 PM

 

对于制造运作系统的使用，目前企业采用的是2种操作模式：

 

1、使用通用的一些制造执行平台，目前提供产品化的制造执行平台的公司虽然很多，但是很多的产品平台是基于以前的一些项目上发展起来的，其行业性比较强，业务模型在使用过程中需要客户化或重新开发的部分比较多。另一部分专注在提供制造执行平台产品和服务的公司相对来说规模都比较小，在和一些大的客户及服务公司对弈的过程中都是出于比较弱势的。所以专注发展的制造执行平台发展到一些商业系统，如ERP，CRM的这种应用规模还有很长时间的路要走。

 

2、通过一些软件服务公司，或是企业本身的IT人员，根据企业本身的业务需求开发一套适合企业本身业务需求的生产执行系统，或是通过客户化开发扩展ERP系统的制造模块来满足企业制造业务的需求。在这种模式下，从短期来看由于是定制化的开发能很好地满足企业的需求，但是从长期来看，这种模式下开发的系统一般生存周期都比较短，特别是现在企业的发展及变化都很快的情况下，需要投入越来越多的人员去再开发和维护。

 

无论采用的是那种模式，一个好的制造执行系统的模型对于企业在选择及开发时都是非常关键的。以下就结合MESA1.0 和2.0 的定义，大致描述制造执行系统的模型架构。以下图的系统体系架构主要参考MESA1.0 的定义，同时考虑向MESA2.0 定义的应用扩展。

 

图 1 制造运作系统体系架构模型

 

针对不同行业或客户的应用软件的共性（通用的业务功能等）和变化性（不同行业或客户业态的特殊性等），考虑系统实现环境（如操作系统、数据库、通信机制、中间件等）和应遵循的标准等因素，设计了如上图所示的制造运作系统平台的体系架构，采用分层的体系结构风格。 采用这种分层的体系架构对于平台产品来说系统的二次开发或配置更简单和易用，对于底层的代码不需要有太多的知识和了解，可以更专注于具体的业务需求，而不是底层的代码技术。而且这种分层的架构可以映射企业业务发展的需求而变化，其改变仅仅在于业务的实现层，而不是代码层面。

 

1、 环境支持层

 

环境层为数据层、业务逻辑层和表示层提供环境支撑，是制造运作系统运行的基础。由于制造业生产执行系统软件对系统的分布性和实时性有着特殊的要求，而不同的环境对于系统实时性和分布性的支持方式是不同的，环境层将这些不同点封装起来，为表示层、业务逻辑层和数据层的构件提供同一规范的接口。环境层主要封装了COM、TCP/IP等底层实现细节。

 

在制造运作系统所支持的环境主要考虑以下所需要的环境：

Windows 2003 服务器

Windows Vista

Internet

Microsoft .Net Framworks 2.0 / 3.0 

 

当然也可以考虑基于Java的架构进行基本架构的封装。但是对于制造运作系统，其界面和可用性及可维护性相对更重要，因此基于.Net 的架构应该更具有普遍性。

 

从性能上来分析，在PC服务器或是小型服务器上的应用，基本都可以支持目前多数制造运作业务的需求。

 

2、数据层

 

数据层一般设计为主数据，业务模型数据和业务数据，工具数据模型四个部分。

 

         i.     业务模型配置数据模型－主要是记录业务流程配置器的配置内容，是基于不同客户的业务需求配置的执行所需要的模型数据，如业务流程，业务操作，用户界面及导航等。这部分的记录通常是通过业务流程配置器来访问或业务流程导入／导出工具可以进行访问。

       ii.     主数据模型　－主数据部分储存搭建应用系统所需的描述信息，主要是配置客户的模型，包括公司，工厂，设备，资源，人员，仓库，库位和工作中心等，还包括产品，物料清单等的要素及打印机，报表，标签等，这些信息用来生成业务数据库的库表结构，支持数据的灵活定制。主数据是业务作业执行时所需要访问的，但通常不进行修改（除一部分外，如产品）。通常主数据可以在制造执行系统内采用配置界面进行配置和维护，也可以通过从其他系统导入，如从ERP系统接受产品主数据和物料清单数据等。

      iii.     业务事务数据，业务数据部分存放应用系统运行时产生的与业务相关的数据，包括各种工单，产品工序数量，库存等数据。数据层向上提供一致的访问接口(ADO、ODBC等)。业务事务数据是由业务运作／作业执行过程中需要访问，增加，删除或修改的数据。通常这部分的数据会随着系统运行的时间不断增加，所以通常会通过备份／维护工具对这部分的数据转移到备份数据库中以保持运行数据库的大小在一个合理的范围，以提高系统长期运行后的可靠性。

       iv.     工具功能数据模型　－如需要系统监控工具，则需要相应的数据记录集，备份工具也需要相应的数据集的支持。这些数据集可能是数据表或存储过程等。

 

 

3、业务逻辑层

 

业务逻辑层设计为两部分：基础组件层和业务组件层。

 

1．基础组件层构件包括：工单创建，工单状态改变，工单汇报，库存调整，库存移动等，提供参数化扩展机制，通过调用数据层提供的统一数据库访问接口访问数据库，支持生产执行等业务过程中的数据加工和流动的灵活定制，是灵活定制业务过程的基础，为构造业务构件和定制核心业务过程提供支撑。例如：工单汇报可以参数化为采购订单的执行、生产工单的执行，发货单的执行等，公式化的组件支持定义业务的数据加工方式和数据约束。

2．业务组件层建立在基础组件层之上，提供不同业务模式下有着特定需求的组件，包括：货物接受，分拣，设备状态改变，设备执行，生产工单汇报何路由等。这些组件往往是为多个行业应用所共同使用，封装了默认的核心业务逻辑，可以对它们进行集成和扩展，构造一套完整的商业解决方案。

 

4、表示层

 

不同的用户可能在不同的环境下使用系统，而特殊的环境将导致对界面支持的特殊需求。即使在相同实现环境下，不同应用系统对界面的要求也不尽相同。

 

在考虑到系统的扩展，用户的需求及开发的周期，系统一般主要采用B/S架构模型，客户端以Internet Explorer为主要客户端，一些主数据的维护界面，报表，绩效等均采用B/S架构的客户端模式。

 

业务执行的界面，缺省采用B/S架构的客户端模式，同时对于业务执行的界面，可以支持Mobile 或Pocket Internet Explorer. 考虑到生产执行过程中部分客户使用习惯，采用部分组件支持ActiveX的模式，可以使用C/S的架构为部分客户的业务提供支持，主要在一些对反应速度要求比较快并且业务简单的业务需求上。

 

在分析通用的行业应用界面的基础上，平台提供多个可复用的界面模板。同时对于基础组件也提供界面定制功能。

 

5、商业系统的集成

 

商业系统的集成主要是考虑到和其他商业应用系统的集成能力，通常和生产执行系统集成的商业系统包括ERP系统，PLM系统，CSM系统等，根据不同业务的需求，所集成的系统也不同，不同系统集成的数据要求也不同。考虑到通用性和目前多数大的商业系统都提供基于面向对象的架构及部分客户化的系统（自己开发的）的相对封闭性，可以考虑采用两种集成机制：

 

1.      业务集成器- 采用支持面向服务架构的模型是非常重要的，通过Web服务的模式和其他的系统集成，采用XML的数据交互换格式。通过对不同业务系统的数据库的Schema的业务数据提供映射，以提高业务集成器的通用性。

2.      同时可以有限的提供数据库之间数据交换模式，为一些客户化的系统提供集成 能力。

 

6、设备的集成

 

设备的集成主要考虑到和生产控制层的设备和执行系统常用的设备的集成能力。主要包括：

1.      OPC的接口 — 目前OPC的标准已经作为控制系统的一个标准，新型的设备或多数老的设备都具备OPC的支持能力，通过OPC的接口支持可以方便的和控制系统进行集成，这些系统包括：PLC，DCS，HMI，SCADA等。

2.      设备的RS232接口标准 — 主要是针对通过RS232方式提供数据通讯的设备，如电子称，测量仪表，RFID等，这种方式主要是通过RS232接口，以ASCII码的方式和计算机进行通讯。

3.      条码打印，扫描设备等的支持，这些设备是在生产执行系统中通常使用的一些设备，采用驱动和数据格式分开的模式进行设计，以提高通用性。

4.      对于不同的行业以及应用的特点，对于设备的集成要求的程度也有大有小。特别是一些流程制造行业，生产管理的很大部分是控制和监视设备，配方的下载和控制等。在这种应用模型中，可以借鉴一些SCADA系统采用的模式，即实时数据库和设备交换数据，在内存层面处理一些时间响应要求比较高的数据，同时和业务运作及业务作业相互集成和调用。

 

7、事件处理机制

 

制造业生产执行系统和一般商业系统在事务处理的驱动机制上有着本质不同的需求，一般商业系统包括ERP系统采用的都是基于时间间隔的事务处理模式，这是由于ERP系统本身对于及时性的要求并不高。但是作为生产执行系统，要求系统具备实时性，系统中的变化要能及时传递到相应的流程或人员。因此在系统架构设计上采用基于事件变化驱动事务处理的机制，能保证信息在生产执行系统内的传递和做到对变化的及时反应。

 

8、工具集

工具集是提供一些实用的工具，帮助将来项目的实施和系统地维护。这些工具集包括：

1.      业务配置器，通过业务配置器，可以方便地配置业务工艺，业务作业等。以实现对业务运作的灵活配置和定制。

基础构件和业务构件只提供了单一的功能，而没有将这些功能连贯成为有逻辑意义的业务运作。通过定制具体的业务逻辑，建立组件之间的关系，由业务配置器进行组件集成，形成具体的业务运作。例如，当系统里已经有了入库单录入和库存帐记帐的功能后，如何让系统知道库存帐要记录新入库的货物而不是其它帐簿呢？这就需要入库事件完成以后激发库存帐记帐的服务，为此业务配置器可以提供业务流程的扩展点，只需将入库单的入库事件与库存帐的记帐服务接口之间的对应关系记录下来，业务配置器就会在事件发生后激活服务，从而完成入库记账流程。

通过业务配置器还可以配置业务操作，实现具体业务作业中的具体的业务操作的实现，如数据的采集，界面的实现，业务组件的调用等。

通过业务配置器配置的流程可以在用户的业务中所见即所得，即时得到应用。通过业务/作业版本的控制能保证用户的业务的改善过程和执行过程的匹配。

 

2.      业务配置导出/导入工具，通过业务配置导入和导出工具可以对基础配置数据，业务配置器配置的工艺路线和作业进行导出和导入到新的系统中。通过这种方式可以方便地实现流程的部署，以及对项目实施的有价值的业务流程的累积，逐步形成实用的不同行业的业务模板。

 

3.      数据备份及转移工具 – 通过数据备份及转移工具可以很方便的通过图形的方式选择生产数据库服务器中所需要的数据进行备份到新的备份数据库中，对于生产执行系统数据库服务器中的数据，可以是按照条件删除/拷贝/移动。使用数据备份及转移工具可以方便地或得数据记录之间的关系，以保证数据的完整性。在很多客户的IT系统中，对于业务数据的备份一般采用的是对于数据库的完整备份和差异备份的结合。这种备份的策略对于系统数据的保持来说没有什么大的问题，但是由于长年累月的积累，生产运行的数据库会越来越大，对于系统的运行效能会有越来越大的影响。通常的策略是生产运行的数据库不长期保存数据，需要保存的数据需要通过归档的策略保存到其他的数据库中，以期提高系统的运行效能。

 

4.      系统监视工具，可以通过网络监视生产执行系统运行情况的工具，方便系统的管理。

 

9、业务过程层

 

业务过程层构件封装了核心制造业生产执行业务过程，是由业务编辑器将不同的业务组件和基础组件，按照用户的业务需求集成起来完成特定功能的用户的业务事务处理。目的是为不同业态的行业过程开发提供模板，典型的制造业生产执行过程包括生产工单开始，生产过程质量，成品汇报，抽检，库存等。在配置具体应用系统时，可根据系统的特殊需求选用这些过程模板，在此基础上进行实例化，得到符合用户特殊需求的生产执行的事务处理过程。

 

10、行业模块层

 

行业模块层为不同的行业业态（汽车，电子装配，机加工，和食品及制药行业等）提供参考模型，包括功能、数据和业务流程；根据不同行业企业的具体需求，通过对行业应用模板进行实例化，就可以定制出适合特定企业需求的具体生产执行系统。

 

11、应用系统层

应用系统层包括根据客户所在不同业态应用系统的特定需求得到的各个应用系统。

 

 

 

在系统的逐步使用且不断发展过程中，业务流程、应用模板和应用系统也将逐渐成为平台的一部分，形成平台中可复用资产的有机组成部分。

 

 

平台中的各构件层次之间的关系如图4所示。下层组件为上一层提供了透明的支撑，上组构件无需了解下层组件内部的实现细节，只需使用下层组件提供的明确定义的接口来实现自己的功能。但是，考虑到性能、灵活性方面的需要，这种层次关系并不是严格的。例如，应用系统开发者可以不使用应用模板层提供的业务模板，而是直接利用流程编辑器来将业务过程层提供的核心业务过程集成到系统中；或者可以不使用业务过程层提供的业务过程，而是直接利用业务配置器将基础组件件和业务组件提供的功能集成到系统中。

 

顽石