Multilevel Order Decomposition in Distributed Production

Transcription

1 Multilevel Order Decomposition in Distributed Production Daniela Wünsch SAP AG, SAP Research CEC Dresden Chemnitzer Straße 48 D Dresden, Germany Aleksey Bratukhin Austrian Academy of Sciences Viktor-Kaplan-Straße 2 A-2700 Wr. Neustadt, Austria aleksey.bratukhin@fiss-oeaw.at Abstract Distributed control systems are emerging as a solution to cope with complexity of production and lack of flexibility of the conventional centralized control system. PABADIS PROMISE provides an architecture for an agent-based distributed control of the production on all three layers of the automation pyramid. One of the aspects of the approach is a multilevel mechanism for order decomposition that increases flexibility and decreases the complexity of the system. 1. Introduction Conventional centralized control systems face challenges in adapting to the requirements of the modern production systems [1]: Unpredictable order flow; customer and production orders are issued dynamically, often when production has already started. Dynamic shop floor; configuration of the resources on the field level changes during production, that makes it difficult to plan the execution of the orders; Complexity of the shop floor and orders; modern production systems are characterized by increasing complexity of both, production orders and shop floor configuration, that makes production challenging. Due to the hierarchical nature, centralized systems are highly static and difficult to adapt to such changes as late changes of customers or new/broken field level devices [2]. Additionally, decision making process is concentrated at the top layer of the automation pyramid (usually Enterprise Resource Planning (ERP) and related systems) and therefore the production planning is hardly able to react to changes or exceptions on the shop floor very flexible. Distributed control systems aim to solve such problems by providing two general mechanisms: Moving the decision-making down to the Manufacturing Execution Systems (MES) layer which has a shorter planning horizon and, hence, is able to react on the changes immediately. Distributing control over a set of independently acting entities that take a part of responsibility for fulfilling the order. That provides concurrent processing and, therefore, minimizes the drawbacks of the hierarchical structures. Both mechanisms require the decomposition of the orders coming from the ERP system down to the MES. In the first case, the objective is to make data from the ERP system understandable to the MES (chapter 3), and in the second case, the decomposition itself is required to assign parts of the production orders and related data to the entities that execute the production to make concurrent processing possible (chapter 4). The static aspects and processes of the order decomposition are based on the PABADIS PROMISE approach (chapter 2). 2. PABADIS PROMISE approach The PABADIS PROMISE [3] architecture offers a complete vertical integration solution for distributed plant automation, providing an agent based system for all three levels of the automation pyramid (ERP, MES, and field control layer). The concept also guaranties horizontal integration of the system, by providing a flexible and adaptive solution on the shop floor. New resources and orders are dynamically added to the plant and the system is able to adapt to the changes PABADIS PROMISE architecture In general, the PABADIS PROMISE architecture consists of three main layers reflecting the automation pyramid structure: ERP MES field control (see figure 1). ERP in PABADIS PROMISE is responsible for the production order planning and control, and for the supervision of resources. Furthermore, it is the interface for the customer and provides an interface to the multi-agent system (MAS), which performs the MES functionalities and plays the key role for the provision of flexibility to the production control. The communication mechanisms used between the ERP

2 and MES are based on web-services that are translated into the Agent Communication Language (FIPA ACL) used on the lower layers. Figure 1. PABADIS PROMISE Architecture The ERP system has three linking entities that fulfill different aspects of the required functionality and provide vertical integration of the production systems: Order Agent Supervisor (OAS); provides supervision of the production orders sent by the ERP to the MES and executed by the Order Agents (OA). Resource Agent Supervisor (RAS); serves as a direct interface between the ERP and field control layer (represented by the Resource Agents - RA) and used by the ERP to influence resource utilization. Product Data Repository (PDR); is used by the ERP and OAs to exchange product relevant data and organized as a cache of the ERP database. PDR saves such data as Bills of Operations and Bills of Material which can be requested by the OA to execute a production order MES in PABADIS PROMISE is represented by the Multi-Agent System (MAS) performing functionalities of MES that can be divided into four groups: ERP interfaces: OAS, RAS and PDR which were just explained; MES kernel: Order Agent (OA); Field control interfaces: Resource Agents (RA); Supporting tools: Ability Broker (AB) and Information Collector (IC) The main agents of the MAS that are responsible for scheduling are the OAs representing production orders, and the RAs providing production abilities. The abilities of the RAs are maintained by the Ability Broker (AB) that manages a database of abilities and provides brokering functionality to the OAs. The Information Collector (IC) collects history data of order execution and resource utilization. These data can be used by PABADIS PROMISE internal entities such as the RAS or by external systems. The field control layer is a distributed environment, controlled by the RAs and offered to the MAS as a set of abilities provided by the field level to the customers of the system and represented by resources. A resource can be a robot, a conveyer line or even the whole plant. That depends on a definition of an ability it provides. An RA resides on a resource it represents to the MAS. Implementation dependent this can be directly on the resource, e.g., a PLC, or in an attached embedded system. This three-level architecture is fully compatible with conventional systems, but the decision-making process is shifted to the lower layers of the MES and field control, making the systems more flexible in adjusting to both, changing environment (field control layer) and frequently changing demand (ERP layer) Production order process The decision making in PABADIS PROMISE is performed by the community of OAs that work independently from each other and coordinate their actions and decisions according to the production orders they execute and a set of social rules that decrease the selfishness of the agents and therefore, increases the optimization of the production. In general the mechanism of the OA life cycle in the PABADIS PROMISE system consists of the following steps: 1. ERP sends a production order to the OAS 2. OAS creates the OA and assigns the production order to it 3. OA retrieves master data from the PDR 4. OA performs order decomposition 5. OA requests the AB for the available resources 6. OA schedules the operation by requesting RAs and reserves one of them 7. RA executes the operation 8. OA waits till the end of the activity execution When all operations of a bill of operations (a.k.a. routing), which is associated to a production order, are completed, the OA sends a report to the OAS that forwards it to the ERP, and terminates itself. Throughout the entire life cycle of the OA, its decisions and actions are based on the set of data that is provided by the ERP system with the recipe of the product. Order decomposition is the initial step of the OA execution and requires parsing of the bill of operations to divide the production into sub-orders with an independent agent assigned to each of them.

3 3. Static view on the order decomposition There are four main data entities that deal with scheduling of the production and usage of resources: Bill of Operations Process Segment Activity Production Order Together, they provide all the information the OA needs to perform order decomposition. Furthermore, the OA operates with physical work pieces, which corresponds to the data structures Material Product Work in Process (WIP) 3.1. Bill of Operations The Bill of Operations (BOO) is the main data the OA uses for the production execution. The OA retrieves it from the PDR and maps it with the parameters provided within the production order. In general, a BOO represents a recipe of the product and defines all activities that have to be performed in order to fulfill the production order (see figure 2). The BOO consists of several process segments (a.k.a. operations), which are interrelated to each other to cover predecessor-successor relationships, parallel or optional procedures and hierarchical relationships Process Segment A Process Segment (PS) itself is a composition of atomic process segments whereby the position of each atomic process segment is defined in an hierarchical fashion. Figure 2 gives only an abstract representation of the BOO with the related activities, where solid lines show sequential process segments with dependencies shown inside the lines, dashed lines show the alternative ways to execute and the dotted lines show relations between the atomic process segments and activities. Logical operations OR and AND are used to show the dependencies and alternatives as well. An atomic process segment is a container for a single ability that is necessary to perform the respective activity. Although, such encapsulation is not necessary, it makes the implementation process simpler. Figure 2 shows the structure of a BOO, which consists of four activities. Figure 2. Bill of Operations

4 For instance, the BOO is Car production, where the first level process segments (1, 2, 3 and 4) represent: 1) Engine production, 2) Car body production, 3) Wheels production and 4) Car Assembly. Wheels production itself is a composition of four single wheel productions. Car body production has two alternatives. Each of the atomic process segments has a corresponding activity: Activity 1 Engine production Activity 2 Car body production Activity 3 Wheel production Activity 4 Car assembly In case of the activity 3, different process segments require the same type of ability wheel production. In case of the PS 2, different activities are required, although the result of the PS 2 is the same. Dependences between different process segments in the given example are the following: PS 1, 2, 3 can be successors and predecessors of each other. Meaning that the order of production for the above mentioned process segments is irrelevant. The same dependence is applied to the PS 3.1, 3.2, 3.3 and 3.4. PS 4 can be performed only when PS 1, 2 and 3 are completed. Each OA operates with a single process segment that can be composed of the several process segments of its own. But it is important to notice that it has to be one corresponding process segment to an OA Activity The lowest entity in the BOO hierarchy is activity, which represents a step in production that involves a resource. An activity is always connected to an ability that is a representation of the capabilities of a resource. From the OA point of view, activity is an instantiation of the ability, meaning ability with fixed values for parameters. If the ability is defined as Drilling, diameter from 1 to 100 mm, handled materials [wood, metal, plastic], then the activity would be Drilling, 10mm, wood Production Order The initial data the MES layer bases its operations on is the Production Order (PO). It is sent from ERP to OAS that forwards it to the OA. In general, the PO defines what kind of product has to be produced with the parameters that are specific to a particular order. A PO consists of the following data: PO identification; that is unique within the system. There cannot be two POs with identical IDs. Product identification; that identifies what type of a product has to be produced within this order. In opposite of the PO ID, the product ID is a reference to the master data that the OA needs to perform the PO. The list of product IDs has to be the same among all entities that are involved in the PO execution processes. In particular, the communication between the OA PDR ERP is based on the assumption that the same identification of the products is used among the entities. The quantity; that defines the amount of products, which should be produced within one PO. All parameters that are necessary to configure the production process such as parameters for the BOO, process segments and activities; The due dates or times such as the earliest and latest start and end date; this data is used for the OA scheduling and re-scheduling and defines the deadlines for the PO execution. The reporting points; that are the time-points in the PO, which define when the OA sends reports to the ERP Material Product Work-In-Process Last but not least, there are three data structures that represent physical work pieces that the OAs operate with. Material A material is any physical component that can be used for production of a product. A material must be identified, must be localizable and the genealogy must be traceable. Product A product is a material, which is a subject of a production order. Each production order refers to one product in a defined quantity. Each OA manages one production order. If a production order is decomposed, several OAs, which are aligned to each of this production orders or sub orders, are created. Work in Process (WIP) A WIP is a material, which leads to a product. A WIP is always controlled by an OA. Reversely, one OA is responsible for one or more WIPs. Thereby, one WIP can consist of many physical objects and has thus an associated quantity. It is assumed though, that all objects belonging to a particular WIP are at the same stage in the manufacturing process. As soon as we want to cover that one OA is responsible for several objects it means that one OA controls more than one WIP. In this case, the WIP ID would consist of two parts the lot ID and the location ID. The lot ID, is the first part of the primary key that uniquely identifies a particular WIP. The second part of the primary key is the location where the WIP is stored. This composite primary key is necessary in order to avoid having to assign a new ID after each manufacturing operation. The downside of this identification scheme is the fact that the key is only valid until the WIP is moved to a new location. Then the key will include the ID of the new location.

5 As an alternative identification scheme, new IDs could be assigned after finishing each operation. If writable RFID tags or similar read/write technology were used, the assignment of unique numbers after each operation may be manageable. Figure 3. Identification of a Work in Process (WIP) In the example shown in figure 3 one OA controls WIP 1 and WIP 2 which both belong to the Lot Out of the three work pieces that have to be processed, two have already been finished (WIP 2). The remaining one (WIP 1) is still located in a container in storage 3. All the above mentioned data are used by the OA to perform the production order decomposition. This mechanism is described in the following chapter. 4. Process of order decomposition Before starting to explain the order decomposition, two types of quantity must be defined. On the one hand, there is the lot-size-quantity as an attribute of a product. This lot-size-quantity is based on the production capacities of the plant. On the other hand, there is the quantity, which is produced within one production order. This amount must not be lower than the lot-size-quantity of the product the production order is referred to. Furthermore, the quantity of a production order depends on other constraints, which are considered during the lot-size-calculation done on ERP layer. This lot-size-calculation refers to the quantity, which should be produced within one production order to optimize the costs. However the lot-size-quantity as a product attribute mentioned above refers to the minimum quantity, which can be processed independently by the plant. In most of the cases the quantity referenced in one production order differs from the lot-size-quantity because the production order quantity is optimized regarding business relevant factors such as the costs and the lotsize-quantity refers to the technical requirements of the plant. If we speak about a lot in the following, we mean always the lot as minimum capacity of the plant. The production order is sent from ERP layer to MES layer at the initialization of the production. From this moment, the MES layer is responsible for the production order and for the order decomposition. For the production order sent by the ERP system, one OA is created, who is also responsible for the following decomposition. There are two steps in the order decomposition: the first step is the lot decomposition and the second step is the operations decomposition. Both steps are optional. That means that only the first step, only the second step, both steps or none could take place. Both decompositions are done on MES layer by the OAs. As it is shown in figure 4, decomposition of the production order starts with the lot decomposition. During this step, the overall production order is split into several production orders, which differ only in the quantity from the original production order sent by the ERP system. For each of these subordinated production orders a new OA is created. The production quantity of these new production orders is based on the production capacities of the plant, which corresponds to the attribute of the product, called lot-size-quantity. This criterion for decomposition shows the minimum number of work pieces that can be processed independently by the plant, called lot size. The lot-sizedecomposition is linked very tightly with the manufacturing planning of the ERP layer. The ERP predefines the lot-size-quantity as product attribute while the execution of the decomposition is done on MES layer. Consequently a part of the planning is relocated from ERP to MES layer.

6 Figure 4. Steps of order decomposition Minimum number of lot size is 1, meaning that each work piece can be assigned to a single OA and therefore be processed individually. But in some types of products and productions decomposition to the singular work pieces is impossible due to the specifics of the shop floor. An example of the singular lot size can be the production of cars, where each car can be produced individually. If the production order from ERP is set to 1000 cars then this order has to be decomposed into orders, which refers to a single car and one OA is responsible for each of 1000 orders. Another example, where the minimum size is not equal to 1, can be the chip production. In this case, the chips are produced together in a lot and cannot be divided into single work pieces. If the production order placed by the ERP is 1000 chips and the lot size is 100 then the order is divided into 10 orders with an amount of 100 chips and 10 OAs exist; one for each order. The operations decomposition is the second step of decomposition (see figure 4). Thereby, each of the OAs tries to decompose its order according to the possible concurrent processing of operations of the product manufacturing. Such decomposition is possible if operations can be done in parallel. If an OA wants to execute the operations decomposition he checks the Bill of Operations for possible ways to split the order. In the case parallel sequences of process segments exist, the decomposition can be executed. As result of the operations decomposition, the production order of the second level is split into sub orders, which are managed by new created OAs. These sub orders refer to the production of Work-In-Processes (WIPs) (see figure 4). Figure 5. Order decomposition at the example of the car production

7 Following the example with the car production, a production order is to produce one car (see OA 1455 within figure 5). However, a car consists of several WIPs: a car body, engine and four wheels. An OA gets this information from the process segments of a particular product type and analyses possible ways to decompose the production. Each of the OAs (OA11-OA11000) does it individually and can divide the sub order into hundreds of further sub orders. The level of abstraction in the operations decomposition is determined by a particular implementation of production planning and shop floor configuration. In the example, shown in figure 5, the production order 1455 is divided into six sub orders, that are responsible for the production of individual components, the WIPs, and the master OA 1455 is responsible for the supervision of production and assembly of the car. As it is shown in figure 4, operations decomposition can be multilevel, meaning that each of the sub orders created after the first phase of the operations decomposition can be further divided into further sub orders. The termination process of the orders is performed in the reverse action. The lowest-level OAs finish their productions and deliver the results to the upper level OAs. The production order is finished when the highest level OA reports the completion of its production order. This paragraph described the order decomposition in a static way. The next paragraph characterizes the collaboration of the OAs related to one production order, which was initiated by the ERP, during the production execution in general and during order decomposition in particular. Figure 6. Material-WIP-Product relation during the production order exectuion

8 5. Relationship between Order Agent and WIP One OA manages the execution of one production order or sub order and thus one OA is responsible for the WIPs associated to this order. The implementation of the relationship between OA and WIP is done in the following way. Before the physical production execution starts, the OA is only logically associated to the WIP. As soon as the production starts, the responsible OA starts by requesting a material from a warehouse. From this moment, the material is a WIP until the execution of the production order or sub order is finished. The WIP is extended from operation to operation because other materials are requested during these operations to fulfill at the end this order. If an OA terminates because the order is finalized, the WIP loses the status of the WIP and is only seen as a material. If this OA is responsible for a production order the WIP becomes a product at the termination of the OA and thereby at the finalization of the production order. The overall process of the collaboration of the OAs belonging to one production order and the transformation process from WIP to the final product is shown in Figure 6. This figure should also help to explain the terms material, product and WIP in a visual way. In the example shown in figure 6 only the operations decomposition took place. However, it is not difficult to extend the example by considering lot decomposition as well, which had been taken place before. In this case, the process of production execution described in figure 6 and in the text above would be the same but takes place several times for each production order. The results of all production orders would be summarized at the end and concluded as the result of the superordinated production order, which could afterwards be confirmed to the ERP layer. The described transformation of materials into WIPs and WIPs into products and materials provides flexibility of the work pieces management as well as allow decomposition of production orders during execution. would be to do the splitting in the reverse order. However, in this case the allocation of resources to process segments became much more complicated because one process segment could be assigned to several parallel resources. The advantage of splitting the order at all is a better reaction to flexibility because parallel lots and parallel operation can be handled independently. The decomposition mechanisms are also the basis for all communications required during the production execution. In the case of exchange between the three layers, the messages would be sent on the same way, the decomposition was done before. Such communications could be necessary for tracking and tracing purposes or because of an exception on the shop floor. References [1] W. Michael Cox and Richard Alm, The right stuff; America's move to mass customization, Annual Report, pp Federal Reserve Bank of Dallas, [2] Lars Mönch, Agentenbasierte Produktionssteuerung komplexer Produktionssysteme, Deutscher Universitätsverlag. Wiesbaden (2006). [3] PABADIS PROMISE Consortium, PABADIS based Product Oriented Manufacturing Systems for Re- Configurable Enterprises, Conclusion The above described mechanisms of the order decomposition as well as the defined data structures provide a solution for distributed production control systems to divide the work load of the production control and make a transition from the initially centralized orders to the independently controlled suborders to improve flexibility of the production system. Among the possibility to split the order in lots and afterwards regarding the operations, another option