Agent-driven distributed-manufacturing model for mass customisation

Yoseba K. Penya, Alexei Bratoukhine, Thilo Sauter
2003 Integrated Computer-Aided Engineering  
Mass-customized production systems are challenging in that they intend to provide custom-specific products at the price of conventional mass production. Since this also includes small production volumes, the manufacturing systems must achieve flexibility, easy reconfigurability, and a totally productoriented approach. In this paper, we introduce a flexible-automation model developed within the scope of the European Union-funded PABADIS project (Plant Automation Based on Distributed Systems)
more » ... meets these r equirements by combining Plug-and-Participate technology with Software Agents. Introduction Enterprise Resource Planning (ERP) has become an important key to the survival of many companies in the current rapidly-increasing pace of business. New facts as deregulation, globalisation, mergers, acquisition and hard competition have forced firms to extremely improve the use of each resource. With this purpose as guideline, the concept of ERP was developed to automate core corporate activities such as human resources, supply chain management (SCM) or product manufacturing. ERP systems, as successors of Management Information Systems (MIS) and Expert Systems, address the problems inherent to the transition from mass production to mass customization [1]. This term, coined by Davis in [2], refers to a system where "one-of-akind product is manufactured on large scale" [3] but at the cost of mass production [4] . This way, the customer might be able to choose from a wide range of varieties and characteristics without having increased the price that would be paid for a fixed-variety product. Following the categorization done in [5] , this paper deals with the implications derived from mass customization as operations management. Within this context, we introduce the on-going research project PABADIS [6] (funded by the European Union under the IMS and IST programmes) that proposes a solution based on the combination of distributed network technology, plug-and-participate features and software agents. The goal of PABADIS is to achieve an intelligent manufacturing system with a product-oriented approach, suitable primarily for single-piece production systems, but also for the challenges of mass-customized production. Nowadays, there is a clear trend toward the decentralisation of manufacturing plant automation [7]. It has been shown that decentralised models are more flexible, robust and scalable than centralised ones [8] and multi-agent systems (also referred to as "agent systems" in the sequel) are a natural tool to address such challenges, since they consist of many physically distributed entities that collaborate to achieve a common goal. Heading this tendencies, the PABADIS project models an automation factory as a system where resource consumers and resource owners cooperate to achieve the best possible production plan. The translation from mass production to mass customization implies a subsequent change from a series-oriented approach to a product-oriented one. Thereby, the emphasis may be shifted from a pure cost effectiveness to a more flexible system, able to quickly respond to different demands. Unlike what exposed in [9], it is not necessary to focus the process on the tracking of the design changes, but on providing updated information about the current situation of the machinery, stocks, and other products. Derived time waste like the set-up of the machines may be reduced with techniques such as Single Minute Exchange Die (SMED), but they still need actualized data to plan the moment when the tooling must be performed. Moreover, such information-flow schemes usually lead to the so-called scheduling problem [10]: how to adapt dynamically the demand to the existing resources in an optimal way (taking into account that a mass-customised system is a demand-driven one). Finally, robustness is mandatory as well, which leads to the requirements that a mass-customization production system should be flexible, fault-tolerant, and it should also have a real-time information system combined with an effective dynamical scheduling. The remainder of the paper is divided as follows. In section 1, we introduce briefly how PABADIS can be integrated within an ERP system. In section 2, the architecture of a PABADIS automation plant is detailed. Section 3 is focused in the plug-and-participate features that PABADIS owns in order to issue a real-time information system and in section 4, we present the way to achieve the required product-oriented approach with a multi-agent system. Finally, we draw the conclusions inferred from the issued argumentation. Modular architecture: divide and conquer Lately, software programs are usually designed as modular architectures. This practice principally presents the following advantages: • Separated development of each module • Isolation of the problems and • Software reusability. In ERP terms, the modularization corresponds to componentization, the division of the tasks and responsibilities of the whole ERP system between different components, as shown in Fig. 1 . This helps the vendors to extend the core ERP system with SCM (Supply Chain Management), CRM (Customer Relationship Management), and other ERP-related solutions. Moreover, the ability to integrate various Information Systems within the ERP is becoming an important factor for both enterprises and vendors. At this point, XML (eXtended Mark-up Language) arises as a reliable solution for a valid and universal interface. In the plant automation pyramid, ERP is on the top layer, control devices are on the lower level and Manufacturing Execution System (MES) and SCADA systems are in the middle. Today, MES typically is a centralized system that controls the execution of ERP orders performed on the shop floor level. The idea behind PABADIS is to decentralize this system by using a community of intelligent software agents in order to make an execution of ERP orders more flexible. Furthermore, the PABADIS approach provides an interface to the SCADA system, gives an infrastructure to control the devices layer and partly implements ERP functionality by providing an interface to the so-called PABADIS community. According to [11] , functions covered by the MES are the following: • Resource allocation, scheduling, and dispatching: This most complicated function of the MES manages the resources of the plans and performs ERP order execution. On one hand, the goal of this function is to optimize the usage of resources, such as machines, tools, labor skills, or materials. On the other hand, the product creation must be optimized as well. In PABADIS this functionality is distributed in the community of agents which act individually with respect to their own tasks, such as product creation or machine optimization. • Document control, data collection, product tracking and genealogy, process management and performance analysis: This function provides information to the ERP system regarding the current situation of the production and product processing. • Maintenance management, which tracks and directs the activities to maintain the equipment and tools, in order to ensure their availability for manufacturing and to ensure scheduling for periodic or preventive maintenance. While the ERP mainly gathers the information about the product to be manufactured, the SCM prepares the raw materials needed for the process and PABADIS performs the development itself. Of course, there are running solutions available (such as FMS) that already fulfil this role. The difference is the fact that PABADIS not only substitutes the MES functionality, but it also achieves a better control of the production by focusing it on the individual development of each product, as it will be shown in section VI. Obviously, this product-oriented approach is ideal for mass-customization systems. Architecture of a networked plant automation The PABADIS plant is composed by several components that interact between them, as presented in Fig. 2 [12] . The automation functions themselves are accomplished by elements known as Cooperative Manufacturing Units (CMUs). They represent the functionality of the plant (like manufacturing facilities, control devices, databases, etc.). A CMU may offer a simple process in one device, the whole functionality of it or even an entire treatment within a group of machines represented by the CMU. The CMUs are divided in three categories, depending on their task [13]: • Manufacturing CMUs are used for the physical processing of products. It and can be a single machine, only one function of a device, a set of modules, or the whole production line at all. This type of CMU always has a hardware (manufacturing) component, which can be used by the agent community in order to execute ERP orders. • Logical CMUs provide computational services like scheduling algorithms or database search or any other calculation and analysis issues. This can be a software program or a logical device. This type of CMU does not need a hardware part, or at least it does not depend on it. Unlike manufacturing CMUs, logical CMUs operate with data instead of work pieces. • SCADA CMUs for Supervision, Control, and Data Acquisition. A SCADA system is centralized by nature. Therefore, attempting to distribute it makes no sense. In fact, the SCADA CMU is a special type of logical CMU providing an interface to a possibly existing SCADA system. A CMU is the gathering of several elements, as shown in Fig. 3 . Principally, they implement the so-called Agent Container (AC) that hosts a stationary software agent (more accurately, the Residential Agent, RA) which acts as an interface between the PABADIS community and the CMU. In this context, the term "agent" means "autonomous software programs that are designed to solve problems by using some means of reasoning and communication" [14] . Moreover, the Residential Agent represents the cleverness of the local machine that cooperates with the system during resource allocation, task execution, etc. All CMUs are connected and form a network. Therefore, not only is the manufacturing itself distributed, but also the knowledge and the information retrieval. . Plug-and-participate real-time information system When a CMU is connected to the community, its Residential Agent contacts a element of the PABADIS model called the Look-up Service (LUS). The RA registers there the capabilities of the machine or group of machines that it represents. This behaviour allows first, to maintain a plug-and-participate (PnP) system and second, to keep updated the information about the plant. Furthermore, the PnP functionality makes the setup of the system easier, in case of tooling, removing of a machine or installation of a new one. Since the LUS renews the database periodically, it is guaranteed that the information retrieved is up-to-date Plug-and-participate systems Usually, distributed systems may be characterized by the spreading of services and components across an infrastructure that provides the whole-system functionality. More accurately, the functionality of such systems is not located at a certain node but distributed across a set of them. Hence, in order to ensure a proper work of the entire system, the components or entities require information about available services at other hosts in order Subsequently, the PA selects the best path and starts allocating a "depth of scheduling" number of tasks on the CMUs that compose such path. This process includes the negotiation with the RAs about which time-slot is available and which PA with lower priority can be forced to give way. Afterwards, the PA starts the migration and physical manufacturing of its associated workpiece. In case that the depth of scheduling was less than the total amount of tasks needed, it starts a new allocation procedure and so on, until the work piece The initial classification of the paths is most likely with respect to processing time, although other criteria can be conceived (e.g., combined execution time and costs). In the example of the drilling-machines it would be as follows: Path 1: 30 min. Path 2: 35 min. Path 3: 35 min. Next, the PA must calculate a more realistic estimation taking into account the actual work load of the CMUs. For this purpose, it contacts all the RAs that form the path with the best estimate (in the example path 1) and get the first available time slot that also fits its own plans (accounting for the time needed for previous tasks, work piece delivery, etc). Finally, it considers if the total time estimation for the path is acceptable and confirms the time slot reservations. It may happen that the CMUs are overloaded and therefore, the time estimation becomes unacceptable due to waiting times. In this case, the PA processes the next best path in the same way, until one of them is suitable. If the PA does not manage to find an acceptable path for the manufacturing of the work piece, it returns an error to the Agency. Work order Execution When the scheduling is finished, the PA starts the migration within the network escorting the work piece on its way through the plant. At this stage, the tasks of the PA are first to control that everything works under normal conditions and second to retrieve the data related to the operations. As mentioned before, the scheduling may not yet be done completely or a re-scheduling process might affect the plans of the Product Agent. Therefore, it could happen that the PA must go through a new scheduling process to reconstruct the execution plan for its work piece. Manufacturing CMU Logical CMU Manufacturing and logical CMU
doi:10.3233/ica-2003-10204 fatcat:ct5qxxrqdvexfius5bwp377noa