Application Environment for the demonstrators and test case Tapio HEIKKILÄ, Jean-Pierre COURTOIS, Hartwig BAUMGAERTEL, Jo WYNS VTT Automation, Kaitoväylä 1, PO Box 13023 FIN-90571 Oulu, Finland, Tapio.Heikkila@vtt.fi A.I. SYSTEMS, J. Wybran Avenue 40, B-1070 Brussels, Belgium, JeanPierre.Courtois@aisystems.be Daimler-Chrysler AG, Research and Technology, Alt-Moabit 96A, D-10559 Berlin, Germany, Hartwig.Baumgaertel @DaimlerChrysler.com Department of Mechanical Engineering, Katholieke Universiteit Leuven, Leuven, Belgium, Jo.Wyns@mech.kuleuven.ac.be 1. Introduction The MASCADA framework are tested within three different manufacturing domains, i.e. car manufacturing (the test of MASCADA), in electronics manufacturing, and in steel production. The two latter ones are clearly demonstrators, and this comes from the fact, that comprehensive testing and evaluation will be done only within the car manufacturing test bed, and only limited tests showing the feasibility of the MASCADA approach will be done within demonstrators. The test bed is described in details in the WP5 report, and only some general outline is given here. There are certain characteristics for demonstrators, which is necessary in WP6 to evaluate the generality of the approach. For example in car and electronics manufacturing customer orders can not be mapped onto the units of semi-finished products, which is the case in steel production. On the other hand, in steel production, there are strong time dependencies of the product properties. In addition, the test bed and demonstrators are all also providing necessary information and experience for the elaboration of the framework and related design guidelines in WP6. 2. Electronics Demonstrator Description 2.1. Case description There is a variety of changes and disturbances for which the manufacturing control system should contribute. Failures and errors originating prom the process (NC/insertion machines, robots, peripherals (feeders etc.), conveyors, AGVs,...) may cause re-direction of the material flows and re-transportation of the parts to new resources. The control system should maintain and have access to the latest available information about the process resources, and should be able allocate and reallocate orders to the available set of available resources avoiding such solutions which result into dead-locks or otherwise drastic reduction of through-put. For example, availability of transportation resources (transportation system) and needs for parts and material transportation (production lines and cells) should be matched together. This should take place within a limited time window ahead, finally depending on the applied production strategies and dominating criteria. There are certain restrictions for the order of process steps depending whether there are both through-hole components and SMD components in the product and whether the components are inserted by automatic insertion machines. Through-holes are inserted before the SMD s if only one soldering phase (wave solder) is used because of the mechanical shocks the through hole component insertion causes onto the board. If two soldering phases are used, typically re-flow is applied first for the other side of the board and then wave soldering to the other side of the board. If the insertion is done manually, then the order is not so critical. In some cases also the mechanical assembly is done in the same factory and production line. If the production lot size is high, this can be automated by hard automation, i.e. by customised assembly machines, or by assembly robots. The typical process steps for these two soldering principles are illustrated in [Lassila98].
goals from user orders, controls JAVA-agent controllers STATION11 CONTROLLER driver messages 111 STATION11 QUEST models LINE1 CONTROLLER AGV1 CONTROLLER AGV1 122 121 STATION12 CONTROLLER STATION12 122 Figure 1. The principal structure of the electronics demonstrator SW system. 2.2. Demonstrator description The basic approach for the demonstrations is to drive the simulation production model directly by the external agent based controls. Here the agent based control is composed of several agents running on one or more Windows NT processes connected in a local area network with TCP/IP protocol. The agent models are implemented in Java language using Symantec s Visual Cafe (2.5) rapid application tools. Those agent controllers which are managing physical machines and equipment (machines, AGVs etc.) are plugged in to the simulator by a specific driver interface (four digit driver codes consistent in both sides). The application software in the simulator implements the simple driver operations (digital mock-up approach). As a production system simulator the QUEST simulator software is used. The drivers in QUEST are implemented as different logics, i.e. process logic, routing logic, AGV logic and so. The organization of the software is illustrated in Figure 1. 2.3. Specificity There is a clear lot size for each order. This is clearly decomposed or mapped to the atomic resources. In other domains (car, steel) the orders are treated more in order to order basis. Also the dependency to the transportation system and the capacity it can provide (the inter-line and storageto/from-line transportations) is critical in electronics manufacturing. A special characteristic is to rely on capacity estimates given by the transportation system. 2.4. Purpose of the demonstrator From the emergent behaviour of the agent system, and from the ability on focusing on local aspects (production lines, transportation, stations within lines) the following benefits are expected: lower down times of the lines and higher through-put avoiding dead-locks and other situations with low efficiency better utilization of the resources, also within unexpected situations (caused by failures or human interventions) easier configurability and reconfigurability of the technology (hardware, software) The demonstrator is used to facilitate running ordinary production lots but with different products, introducing rush orders, and handling disturbances. The rush orders are introduced in arbitrary times by human operators, and disturbances are introduced by disabling one or more resources by disabling their simulator counterparts. In each case the thru-put of the whole system is observed.
STORAGE STORAGE AGV AGV1 10 20 30 Conv11 Conv21 Conv31 11 21 31 SMD1 SMD2 SMD3 SMD1 SMD2 SMD3 Conv12 Conv22 Conv32 12 22 32 AGV2 MAI11 MAI21 MAI31 Conv13 Conv23 Conv33 13 23 MAI11 MAI12 MAI21 MAI22 MAI31 Conv14 MAI12 Conv24 MAI22 Conv34 14 24 34 AGV2 AI11 AI21 AI31 Conv15 15 Conv25 Conv35 AI12 AI11 AI12 AI21 AI31 Conv16 Conv26 Conv36 16 26 36 AT11 AT21 AT31 AGV2 Conv17 Conv27 Conv37 17 27 37 AT12 AT22 AT32 AT11 AT12 AT21 AT31 AT32 Conv18 18 Conv28 28 Conv38 38 AGV AGV1 STORAGE STORAGE Figure 2 Conventional and very flexible process flows in electronics manufacturing 2.5. Principles of the approach There is a variety of changes and disturbances for which the manufacturing control system should contribute. Failures and errors originating prom the process (NC/insertion machines, robots, peripherals (feeders etc.), conveyors, AGVs,...) may cause re-direction of the material flows and re-transportation of the parts to new resources. The control system should maintain and have access to the latest available information about the process resources, and should be able allocate and reallocate orders to the available set of available resources avoiding such solutions which result into dead-locks or otherwise drastic reduction of through-put. For example, availability of transportation resources (transportation system) and needs for parts and material transportation (production lines and cells) should be matched together. This should take place within a limited time window ahead, finally depending on the applied production strategies and dominating criteria In the demonstrator the system is agentified by introducing agents to production lines and stations inside the lines, storage room controllers and opertors inside the sorages, and AGV transportation syste and indivisual AGVs. The goal for using agents is to create more flexible material flows (semi-products, parts&materials) by moving the decisions of transportations down in the hierarchy. Currently the transportation requests (for manual transportation) are created globally (review of the order queue by storage/transportation/line personal or by shits foremen). In agent like solution the decision is done by line controllers (decide which machines do what and when, which leads to the varying need of materials within different machines); the machines are responsible of acquiring parts & material so that they can maintain required procution Two types of algorithms are demonstrated: conventional dispatching rules, and emergent control. In the case of conventional ones rules like earliest-due-date and first-come-first-serv e are
applied throughout the system (line controllers, storage room controllers, AGV system controllers). In the case of emergent control the centralized decision making is reformulated to follow the distributed PROSA architecture. Order agents are introduced to take responsibility to find suitable resources for the production orders. All resources are connected based on the functional topology of the manufacturing system, defined by the process plans of the products, and the eligibilities of the resources to carry out certain process steps (in the process plans) for certain products. Instead of global search the basic idea is to maintain on-line information about the possible capacities of the system. This is done by propagating thru-put related data (lead times and capacities) upstream, and especially considering the real situation of the resource regarding confirmed orders for the resource (= reservations of the resource to an order within time). When only best (or two to three) routes per product type or product group are considered, the number of maintained information becomes substantially smaller (optimality). The role of the order agent is to use this on-line information, and make some inquiries downstream, starting from the available first resources within the routes, or virtual lines, and see how the possible thru-puts of (or capacities available for) other orders (all product types) behave, if the resources within the best route were allocated to that order. Such routes can be selected, which do not cause substantial reduction of thruputs for other possible orders (collaboration capability). In addition, the order agent will also test situation when each of the resource within the considerd route is broken down; such routes with second best routes should be selected, which do not cause substatial overloading of resources, i.e., the best thruputs of other orders would be available only using certain resource or few resources (proactiveness: avoid creating global bottlenecks within disturbances). In the case of disturbances, the order agent re-batches the order s original lot within the remaining part of the original batch, and routes this based on the available information of the optional routes downstream before the disturbed reosurce (reactivity). Because all the communication, both in maintaining the best available routings on-line, and trials to see what selections of certains routes will affect, is done only peer-to-peer (implicitly, based on the rpoduct type dependent connection information of the resources), there is no need maintain any global descriptions or calculate global features. This comes implicitly because the global properties are accumulated step by step in maintaining the thruput data, and also propagating the consequences of reserving the resources within the route for an order. The collaboration and proactive capabilities are evaluated by determining their goodness characteristic values, which are then combined. The order agent then selects that route which gives best compound value for compound optimality with collaborativeness, and proactiveness. Finally the role of the staff agent is to set the weights for optimality/collaborativity, and proactiveness to make the system work in an opportunistic way (closer to optimum) or carefully (beware of disturbance effects). 3. Steel case demonstrator description 3.1. Case description The steel case addresses the steelmaking area of the steel plant. It includes typical meltshop facilities, from the supply of pig iron at the converters, to the cutting of the slabs behind the continuous casters. The demonstrator focuses on flat product production processes, as it is the usual market of A.I. Systems, but it could easily be adapted to other type of steel products. 3.2. Demonstrator description The demonstrator is built with G2 (Gensym). A common plant layout has been chosen, with a set of representative facilities. Suspended cranes ensure the transport of the ladles between the facilities. A simplified model drives the operation of each facility and crane. Real data can be given as input instead of the model. The number of facilities and their interconnections can be easily changed. 3.3. Specificity The steel case demonstrator has some domain specific elements: steelmaking is a semi continuous process presenting a discontinuity. Liquid steel is treated in batches. But batches are merged in a continuous solid steel strip at the caster. Customer orders can not be mapped onto the units of semi-finished products.
Desulphurisation Converter loading O 2 blowing Converter lining repair Chemical analysis Converter unloading Vacuum degasing Ladle treatment Ladle lining repair Trimming Ladle Furnace Casting Tundish lining repair Cutting Figure 3. Steelmaking simplified process diagram The product properties are time dependant. The liquid phase involves high temperature and hot steel is subject to oxidisation. The sequence of operations requested to reach the right quality of steel requires a lot of engineering and metallurgical expertise. This demonstrator makes explicit call on the product agent. Due to the wear of the lining, several resources need frequent repairs that can be considered as processes as well. A specific set of order agents will be needed in the system to handle those processes. Although the steelmaking process is somehow unpredictable, a good scheduling can however result in huge gains. The demonstrator uses an initial schedule delivered by existing A.I. Systems software to drive the production. Scheduling can be seen as a kind of batching (in the sense of grouping the cars by colour in the automotive case). Given the nature of the logistics and process constraints, scheduling rules are more extensive and quite complex. Complex logistics and process constraints, sometimes contradictory from one production unit to the other, result in complex scheduling rules. 3.4. Goals and measurements The meltshop is committed to absorb the pig iron supply from the blast furnace. But it has also to balance the production flows among the downstream lines. Therefore, the objective of the
meltshop control system is to safeguard the throughput, not to maximise it. In function of the characteristics of the final product, the batches undergo different treatments resulting in different process time. Balancing the product mix is thus a way to control throughput. Given the target throughput and the equipment capacity, the scheduling package is able to chose the best product mix in order to saturate the converters and the casters. The lines are balanced. The main requirements for the control system are: routing control of the steel batches through the transportation system autonomous decision on solid strip cutting when uncertainties on batch weight are redrawn adaptation of the initial schedule if production problems occur (quality miss) Given the limited size of the WIP inventory in the meltshop and given the relatively long lead-time of the operations, re-scheduling is not a critical issue and has little interactions within the control system. Existing scheduling packages can easily be used for this purpose. On the contrary, negotiating the routing when several hundred of different qualities can be produced, and co-ordinating the transport of empty and full ladles between the facilities is a critical issue. As a consequence, the demonstrator mainly addresses the issue of routing negotiation and crane movement control in the scope of Mascada. The scheduling package takes capacity constraints of the meltshop facilities into account, but neither the routing possibilities nor the constraints of the transportation system. Hence, throughput can be highly affected by transportation problems (jams, delays, trajectory conflicts ). The control system must thus ensure the transport system is able to cope with the production schedule, i.e. steel batches are delivered on time at processing facilities. Difficulties come from limited or competing transport device movements, and from competing transport of empty containers needing maintenance process. 3.5. Purpose of the demonstrator The purpose of the demonstrator is to assess the applicability of the proposed solutions across applications, specifically in the field AI Systems is active in. Ultimately, the demonstrator should allow evaluating the feasibility of a sellable product, and testing the interest of the market. The following advantages are expected: Gain in software development and maintenance. Gain in system configuration. Gain in system tuning. Lower decision step for potential customers. A demonstrator easy to configure allows simulation and evaluation of the product at low cost. 3.6. Principles of the approach In a first phase, the demonstrator will assess the ability of the system to cope with lay-out adaptation and apply the pheromone algorithms to the meltshop control system. The control system should be able to ensure proper routing of theorders through the meltshop facilities, and to take appropriate decisions whatever changes or disturbances occur in the meltshop. In function of the quantity of pig iron to absorb, the capacity of the meltshop may be adapted by shutting down or putting into service some facilities. Delays, failures or breakdowns may affect the production processes or the transportation system and require re-routing of the orders, or even re-scheduling. In any case, the control system should safeguard target throughput and ensure transportation system doesn't hinder the completion of the schedule. In current operations, human dispatchers take routing decisions and give instructions to crane operators on the spot in function of the course of operations on the floor. But JIT strikes in steel production too, and the need for automation increases with the complexity and the flexibility of the production processes. The demonstrator will automate the meltshop logistics and apply the Mascada control algorithms to the meltshop control system. In a first phase, it will assess the applicability of the algorithms in this peculiar context as well as the ability of the system to cope with lay-out adaptation. Resources agents will control all facilities and equipment of the meltshop. In function of the sequence of operations delivered by the product agents, production orders and maintenance orders will negotiate their way through the various processes and request transport from the transportation system. Decisions are taken locally and can be reviewed in function of the course of operations. Processing is constantly monitored by order agents. Staff agent may add for co-ordination
and proactiveness to make the system work in a more optimal way. An important parameter for the productivity is for example the number of ladles in circulation. More ladles in circulation means less probability of deadlocks, but big savings can be reached by cutting the number of ladles. To safeguard throughput, transport priority should go to orders heading for or leaving constrained resources. Constraints may move over time in function of the product mix. Algorithms should avoid crane conflicts and choose the routing to balance the load of the resources. Time plays an important role as characteristics of the product (composition, temperature) are evolving throughout the process. Spreading information over estimated order processing time, transport devices status and estimated transport time, among others, will allow for more appropriate decision taking as orders get through the processes. 4. Automotive testbed The automotive case serves as the main testbed for the Mascada control system. It will be described in detail in the deliverables of WP5. Here only a short description is included to show the differences and similarities with the two demonstrator cases. As a consequence, this section will show a lot of overlap with the WP5 deliverable. 4.1. Case description For details of the properties of the plant, we refer to the report Deliverable of Work Package 5a: Plant configurations of the main testbed: Painting Center of the Mercedes-Benz passenger car plant at Sindelfingen. The short introduction to the automotive case: The result of the painting and inspection processes will determine the eventual need for further processing: repair preparation, grinding, heavy repair, repaint,... Therefore, the route of the car can not be determined up front. The data analysis shows that the yield of the painting process is influenced by the batch size of cars of the same color. Cars coming from the repair loops break the batch size, and therefore increase the risk of sending even more cars towards repair and repaint processes. The workload of the painting units depends on their yield, since the units also have to repaint the badly painted cars. The transport system contains more than 200 routing devices (lifts, crossings, sorting buffer,...) where a car has/may decide which way to go. These are the decision points for the control system. Figure 22 shows the Arena model of the physical layout of the plant. The main goal of the plant is to increase throughput: number of cars produced per day. 4.2. Demonstrator description The agent based control system is written in Java and can run on any Java Virtual Machine. Currently, we use Sun s JDK on Windows NT. A digital mock-up of the physical plant is build in the Arena simulation tool (see Figure 22). The control system communicates to the digital mock-up via sockets. The control system sends commands to the digital mock-up: Lift X: move car from entrance Y to exit Z, SortingBuffer1: release car X,... The control system receives status information from the digital mock-up: car X arrived at lift Y, car X painted, car X needs heavy repair,... The digital mock-up replicates the behavior of the real plant, including the statistics to generate painting problems, and mimicking the influence of batching of cars with the same color. The simulation in Arena is proportional to the real time. This is important, since the control system shall be given the time to decide where to send a car. The effect of the calculation time on the physical flow of cars in the system shall be minimized. 4.3. Specificity The control system (also the current one) does not know up front what type of cars (body type, color) will arrive at the input (North bridge). It is only when the car passes the first sensor at the first crossing of the plant (just behind the North bridge), that the control system reads the identification number of the car, and can read the car type and color information. 4.4. Purpose of the new control approach The new control system shall show a higher throughput (# cars / day). This can only be achieved by better reaction to disturbances.
S B 1 S B 1 S B 1 e A r e n a n u m b e r : e I Id ld el e Ie d l e le E N S W e S B 2 e I d l e Figure 4: Part of the physical layout of the car painting plant. Increasing the throughput can be achieved by the minimization of losses. In this case, this is requires: increasing average painting batch size of painting of batches of cars with the same color, reducing the planned work-load on the (current) bottleneck machines, avoid blockages in the transport system, avoid blocking a (bottleneck) machine by a full buffer behind the machine or the transport system behind the machine, avoid starving a bottleneck machine by an empty buffer before the machine or the transport system before the machine, satisfy the customer by delivering cars before their due-date. The control system shall allow changes in the system. This will be evaluated by applying the control system to a totally new layout of the car painting plant (see report on deliverable 5a). 4.5. Principles of the approach This details of the new control system will be described in the final WP5 deliverable. Main principle of the new control system are: The decision points are distributed over the transport system: at every routing device (lift, crossing, sorting buffer,...) a decision is to be made which car goes where and when. This decision is made by negotiation between the local order agents (cars) and resource agents (routing devices, conveyors). The decision is constraint by the layout of the transport system, and the abilities of the processing stations. The pheromone based control algorithm shall distribute and transform local information, in order to represent at each distributed decision point, suitable information about the global system state. This shall allow the local agents to make a founded decision. If possible, the control system will use no a priori information about the system layout and
capabilities. This will increase the applicability of the control system to different plants. As a consequence, aggregated transport resource agents (e.g. buffer before repair) are avoided as much as possible. They hinder the adaptation of the control system to changes and disturbances: the aggregated transport resources impose a certain usage of a section of the transport system. For instance, the buffer before repair will control the underlying conveyors and lifts in order to get a buffering behavior. In the new approach, such buffering behavior shall emerge out of the constraints and goals of the involved car order agents, conveyor agents, and lift agents. This way, the buffering behavior will also automatically disappear in case the current situation requires these lifts and conveyor to quickly move cars, instead of storing them. 5. Acknowledgement This paper presents research results obtained through projects sponsored by the European Community. The Mascada project is supported by ESPRIT LTR. The scientific responsibility is assumed by the authors. 6. References [Lassila98] Lassila K., Heikkilä T., Requirements for Flexible Manufacturing in the Production of Printed Board Assemblies. Proceedings of First International Workshop on Intelligent Manufacturing Systems - IMS Europe 1998. 15 17 April 1998, Lausanne, Switzerland. Pp. 327-340. [Que97] [Are97] QUEST Release Notes Version 3.0., Deneb Robotics, Inc. Auburn Hills, Michigan, USA, 1997.. Arena User's Guide, Systems Modeling Corporation, Sewickley, USA, 1997.