مدیریت سفارش مشتری در تولید مستقل خدمت محور

One of the most important problems when considering the design of manufacturing systems based on SOA paradigms is the integration of shop floor devices in the business processes at the enterprise level. This paper presents the design and implementation of the Customer Order Management (COM) module based on SOA architecture in the context of holonic manufacturing systems. The COM module is integrating with SOA enabled shop floor devices using industry standards. The implementation leverages a multi agent system suited for industrial applications integrated in a SOA environment capable of dynamic BPEL workflow generation and execution. The prototype consists in a SCA application for core COM module functionality and an extension for NetLogo MAS platform for SOA integration. The COM module interacts with the MES layer using real time events handled by the BPEL process implementation in the execution stage. A web based portal frontend for the COM module has been developed to allow real time tracking of customer orders, providing data about product batch execution and individual progress of each product on the production line.

Manufacturing systems have evolved from simple production lines that were able to produce a limited set of products, to complex environments that can produce an almost infinite number of different products by combining various operations and procedures. This evolution is driven by the changes in the market environment, where customers demand new products with more specific requirements, to meet their business goals. Also, there is an increased need for enabling the production lines to react to unexpected situations, such as resource break-down and rush orders with minimum impact. This aspect reduces the overall production costs and offers more flexibility for companies to respond to market changes. These intelligent production lines are designed based on the holonic concept [1], where a holon is defined as an entity that is simultaneously a whole and a part. Starting from this definition, manufacturing systems are represented as hierarchies of holons – each one related to components of the material flow (products), the production flow (orders) and the processing flow (resources), and encapsulating specific functionality of the component at each level of the enterprise processes in which the component is involved. The PROSA reference architecture [2] for holonic manufacturing is adopted, extended with the auto-supply functionality, the basic holons being defined as order/supply holon, resource holon and product holon. Each holon contains a physical part (the manufacturing component it represents) and an informational part (the agent describing the component's behaviour). Current research is focused on service orientation of holonic manufacturing systems and is based on new concepts such as Service Oriented Architecture (SOA), Enterprise Service Bus (ESB), Web Services, Manufacturing Service Bus (MSB), Distributed Intelligence (DI) and product-driven automation, Service-oriented Multi-Agent Systems (SoMAS), resource service access model (RSAM) [3], [4], [5], [6] and [7]. At the aggregate level of a manufacturing enterprise, SOA is the standard for business process modelling and management [Forrester Research, 2005].The integration of the shop floor processes in the enterprise business processes requires service orientation to fill in existing technological gaps and solve legacy problems. An end to end integration, from the initial offer request to the manufacturing execution system and supply chain, provides enterprises with the ability to gain agile control of all activities, allowing flexibility and constant improvement. Other advantages of service orientation for manufacturing systems include central and integrated audit track allowing enterprises to comply with specific laws that apply to the products [IBM, 2005; [8]]. The primary goal of Service Oriented Architecture in the context of manufacturing enterprises is to align the business layer information flow with the technology specific information flow – the latter being partitioned on two layers: (1) the business layer (management of customer orders); (2) the shop floor layer (execution of customer orders). SOA is the bridge that creates a symbiotic and synergistic relationship between the two layers. SOA is an IT system model providing flexibility to the enterprise in the way business applications are created. SOA is not just focused on application integration, but also on application construction from existing IT assets. This type of architecture allows for the creation of composite business applications from independent, self-describing, and inter-changeable code modules called services. These services are available for use on a services bus, and they can be arranged together into a business process or composite application using process choreography. Thus, the major components of SOA are: services; services bus; process choreography – composite applications; message transformation, mediation and routing; services registry [9]. The Service Oriented Enterprise Architecture (SOEA) for the generic business layer of a manufacturing enterprise is shown in Fig. 1. The set of business processes and business services that a given business user will consume (consumers of processes and services) are: Offer Request-, Production Order-, Rush Order-, Customer and Supplier Relationship-Management. Full-size image (47 K) Fig. 1. The Service Oriented Enterprise Architecture for the business layer of manufacturing enterprises. Figure options Business processes should be treated as compositions of other business processes and services and therefore be decomposed into their subordinate sub-processes and services. Services (including business processes as services) can then be detailed in service components—converted into a detailed set of definition metadata that will describe that service to the information system. The Enterprise Service Bus (ESB) is a flexible connectivity infrastructure for integrating applications and services. One of the objectives of an ESB is to reduce the number, size and complexity of interfaces in a SOA [10]. An ESB performs the following actions between requestor and services: • Intelligent message routing between parties. • Conversion of transport protocols between service consumer and service provider. • Transformation of message formats between service consumer and service provider. • Handling business events from various sources. When SOA is employed as an integration strategy, it brings about a catalogue of self-describing, atomic business services that are used together to create a business process. Often, a business event (e.g. one rush order arriving at the customer order management module) will need to trigger interactions between many different business and/or shop floor manufacturing systems [11]. These interactions are achieved using process choreography within an SOA. Process choreography allows for multiple business services to be combined and used together to implement a business process. Process choreography in SOA is realized via BPEL (Business Process Execution Language) [12]. The resulting set of business process definitions, services, and schemas will make up the logical architecture of the high layer (business) manufacturing application. This logical architecture is mapped to a physical architecture relating the components of the application to a set of functional capabilities for the existing component technologies and languages, a topological structure to establish points of separation and distance and an assessment of the existing legacy inventory to drive an implementation plan. This in turn should be conditioned by non-functional (quality-of-service) requirements of the deployment from which one can establish which approach for integration should be used. The security and integrity requirements of the deployment, the flows to be monitored, the architectural requirements of the data system and the needs for business intelligence are identified and fitted into the governance model [13] for the enterprise layer of manufacturing business processes [14] and [18]. This mapping into the physical architecture will conclude with deployment architecture—a specification of the actual hardware, capacity, operating system, language, availability, policy and management system requirements to be actually used in the production system (the service providers). From an industrial perspective the first challenge in aligning the enterprise architecture with SOA principles is adhering to standards [19], [20] and [21]. In the next section of this paper the most important standards used in manufacturing industry are described and categorized based on the layer where they are used. In this context a classification of shop floor devices is presented, describing the standards that apply to each. The main contribution presented in this paper is the design and implementation of a BPEL based customer order management module that integrates with shop floor devices by dynamic workflow generation and execution integrated with a MAS based MES system. Agents representing products on the production line are capable of BPEL execution using an external SOA engine connected to the MAS platform. Finally a prototype web based portal application for COM module frontend is presented that allows real time tracking of customer orders at product batch and individual product level.

In this paper we have described the architecture and implementation of the Customer Order Management module in the context of Holonic Manufacturing Systems, based on SOA paradigms. The COM module presented is implemented using a BPEL SCA application running in a standards based SOA engine. The customer order is decomposed in aggregate product orders which are created by dynamic BPEL workflow generation and execution. We have presented a multi agent control system for SOA enabled devices developed on top of NetLogo platform, enhanced to allow BPEL workflow execution. The execution can be simulated (at NetLogo layer) or it can be a real execution on shop floor devices driven by the NetLogo agents. Future work is focused on extending the architecture to use exclusively Class III SOA enabled devices which would allow migrating the dynamic BPEL process generation to the SOA enabled devices layer. This approach would allow a truly collaborative execution environment at MES layer driven by the incoming customer orders.