Geoff Mueller
E2M, Inc.
Norcross, GA
INTRODUCTION:
E2M / Polytron has concluded our optimization of the labeler area on line X. We found that the
area, particularly single filer B, becomes unstable during low prime. After testing different control logic, we found three specific control changes that stabilize the area. The first two involve timers on photo eyes. The third utilizes the labelers low speed for running. Currently low speed is used while stopping the machine only. Since the single filers do not currently run at low speed for more than ten seconds, we need to verify that they will function efficiently. This will be done on Friday 3/2/2001. If they can’t function efficiently, then both single filers will be re-geared, to handle 300 bpm. Update:
After testing the system, the PolySim results were verified. The real system behaved as expected, saving us $15,000.
THE PROBLEM:
There has been feedback from the operators that the labers have been going off and on frequently. Much of the labeler room downtime has been attributed to this problem. To identify the specific cause, we utilized our PolySim process. It enables us to see how different control logic affects the line. After modeling the system we found the following pattern shown in figure 1. The bottle per minute speed of labeler B (the thick black line in the bottom graph) fluctuates a lot until the first downtime at 15 minutes. After this 2 minute downtime, the instability goes away. By watching the animation as the model ran, we traced the problem to PE4510. This photo-eye causes the single filer to start and stop about every two minutes. As a result, labeler B is starved.
Figure 1: Current logic showing the instability at low prime conditions.
This type of problem is very hard to find by watching the line, because it most likely causes the labeler to fail, backing up the system. This hides the true cause of the downtime. Once the system recovers, the problem goes away until the bottle supply is depleted again. So labeler B tends to fail when the accumulation drops below 10%. This coincides with the operator’s perception that labeler B doesn’t work as well as labeler A.
THE SOLUTION:
Using the PolySim process, we adjusted the controls to balance the system. Changing the timers on photo-eye PE4510 to match eye PE4512 stabilized single filer B. Now however, the graph in figure 2 shows both labelers running worse.
Mueller
Figure 2: With single filer B stable something else is still causing the labelers to stop.
Analyzing the graph, we found that the labeler’s low speeds were only being used for 10 seconds before they stopped due to low prime. We consequently changed the low speed eye to one 10 feet further up stream, allowing the labelers to move into low speed long enough to avoid stopping. The optimized system is shown below in figure 3. Now both labelers drop to low speed three times during low prime, but don’t stop. At this point we are ready to make the logic changes, but there is a question as to whether the single filers can run efficiently with the labelers at 300 bpm. They were designed to range from 400 bpm to 1200 bpm, which isn’t ideal for current running conditions. However, they seem to run fine if the in-feed conveyor to each single filer is restricted to 300 bpm. On Friday 3/2/2001, we are going to test this method. If it works, we can avoid regearing the single filers, saving $15,000. If not, we’ve already prepared the order to get the necessary parts from Alliance.
Update: After testing the system, the PolySim results were verified. The real system behaved as expected saving us $15,000.
Optimizing PLC Controls On A High Speed Bottling Line
Figure 3: Corrected logic showing the greater use of low speed to prevent taking the labelers down.
EMULATION OVERVIEW
Ian McGregor
Brooks Automation
Salt Lake City, UT |
|
Richard A. Walters, Jr.
Alvey Systems, Inc.
St. Louis, MO |
Abstract: This paper details the work done in applying simulation technology to the commissioning phase of automated systems in order to reduce unknowns and their associated costs. The problems encountered when installing and verifying the operation of control software on a complex system of any type are well known. When this has to be done within the time constraints of the project’s commissioning phase; the result is often unsatisfactory for all concerned, leading to project overrun, extended ramp times and rising costs.
In many cases, it is possible to carry out a significant portion of the standard logic testing and acceptance steps by replacing the physical system with an accurate AutoMod model run by the actual control system. The simulation model has to be capable of reacting to the control system in exactly the same manner as the physical system, and of providing the same responses. The control system should not be altered in order to run the model. This phase can be initiated as soon as parts of the control system are ready for testing, thus eliminating an unpredictable and often time-consuming element from the commissioning period.
Assuming simulation was carried out during the analysis and design phase of the project, the model needed for emulation can be available as soon as the design specification is agreed upon. The paper will describe how a standard analysis and design simulation model can be constructed such that only minor modifications are required to use it for emulation.
The advantages of using emulation to ease commissioning are many. Apart from those already cited, the end user of the system can be trained on the control system and any associated data entry screens before the system goes live, allowing mistakes to be made in the safety of the virtual environment. The 3D model used shows users the consequences of their actions in a way that is often impossible in the real workplace, and any operational situations can be conveniently created to test or understand the control system response.
The technology used to enable this emerging use of simulation (DDE, Sockets and OPC) is covered, as are several early implementations such as those at Coca-Cola Enterprises and General Motors. Current developments attempting to facilitate the wider use of this technology are also explained.
INTRODUCTION
Users of industrial simulation products have long requested a way to eliminate the need to reproduce the logic built into the simulation model when the experimentation and analysis phase is complete and the real control system has to be developed. There will always remain concerns about how closely the simulation logic reflects the real control system and any method or product that can reduce the redundancy, doubt and costs inherent in the current approach will be very welcome in industry. From a simple standpoint there seem to be two possibilities; either to generate the control system from the model, or to use a real control system to provide the control decisions within the model. Unfortunately,neither of these is currently a pragmatic solution as a simulation model and a control system have two very different sets of functional requirements. A simulation product must be flexible, resulting in models that are easy to construct and to modify, and it must execute as rapidly as possible in order to perform experimentation and optimization runs in an acceptable time frame. A control system is not designed to run any faster than in real time, and its architects are concerned primarily with robustness and reliability. The flexibility of the simulation product means that attempting to generate efficient control program logic from it is an onerous task, unlikely to succeed consistently. Replacing the simulation model logic with a real control system results in an impracticably slow model totally unsuited to the requirements of experimentation and analysis. Fortunately there exists a third solution that can not only accommodate both sets of requirements and minimize redundancy, but which also offers other advantages that make it attractive to end users and systems integrators alike.
SIMULATION AND EMULATION
For the purposes of understanding the work described
in this paper it is useful to consider an example of the
differences between the two concepts of simulation
and emulation. A simulation model is representative of a system or part of a system comprising the material handling hardware and the control system. Loads are introduced to the system in order to test and observe its response as a way of improving it according to some stated objective. If the model is representative of the reality, then improvements in model performance can reasonably be assumed to signal similar improvements are likely in the real system. Simulation is used as a way of making more informed choices concerning the various parts of the proposed system, and results in a more thoroughly researched solution than would have been possible without it. Simulation naturally precedes the build of the various system elements, and as it leads to the choice of one solution among many, its effects are often frustratingly hard to quantify. An emulation model has a much simpler aim, and the most visible and measurable effects are observed at commissioning. An emulation model provides responses to the actual control system, and testing can begin as soon as the control system is ready, assuming the simulation model exists. The model replaces the future physical system and the control system should remain the same for both the model and the real system. An emulation model provides an environment in which to test a standard set of predictable operating conditions and demonstrates the functioning of the control system. It is unlikely that stochastic events would be included in an emulation model – although these are an essential element of an analytical simulation study, the emulation approach is much more that of a checklist. Clearly, there is a place for both simulation and emulation models in an automated material handling system project.
THE ADVANTAGES OF EMULATION
Emulation is of interest to both end user companies and integrators, and for different reasons. Although
both parties share the common goal of bringing a new or modified automated system into production on schedule and under budget, each also has their own unique concerns.
Complete control system testing
Automated systems represent considerable capital outlays that are amortized over time periods usually longer than manufacturer guarantees. Emulation provides a credible means by which end users can test the control system performance under all conditions imaginable; not just those which are feasible within the tight time constraints of the commissioning window. Many different aspects of the installation currently need to be verified during commissioning – including safety aspects, the physical accuracy of the placement of the various elements, and so on, and these all compete with the testing of the control system. While it is often not possible during commissioning to reproduce the peak
conditions the control system was designed to cope with, the emulation world is under the complete control of the user.
End user training
Emulation models can be connected not only to the control system, but also to the Human-Machine Interface (HMI). Operators can be trained in the use of the system in a way that is impossible in the real world as the 3D representation of the model can be viewed at any angle, in detail or in its entirety. Data can be displayed concerning any load, order, conveyor section or vehicle, for example, to inform the operator of the consequences of their actions. The real world rarely offers such a wealth of feedback and system use suffers as a consequence. The emulation world is data-rich and risk-free, whilst also providing a realistic and reliable environment in which to gather experience with absolutely no negative impact on production. Ramp problems often arise due to a misunderstanding of how the system reacts to certain inputs. This type of problem will arise more frequently as systems continue to become more complex.
Reduced installation risk
Integration companies often use sub-contractors for anything from a project-specific piece of equipment to conveyor control code. Although the integrator remains responsible for the overall success of the project, they are often obliged to rely on resources outside their control in order to meet the project deadline or budget. The emulation model provides the means to bring together the various system elements and control programs before commissioning and to verify their integrated operation. This has two desirable side effects; the system can be debugged and developed outside the commissioning window and away from the end user site, and the end user can be reassured at an early stage that the system will work as planned.
Reduced ramp problems
Ramp problems encountered after the hand-over phase are notorious for eating away at alreadydepleted profit margins and are a major source of dissatisfaction for the end user. Technicians are obliged to remain on site with very little to do apart from reacting to events thought to be erroneous. Inexperienced operators will often claim that a malfunction has occurred when in fact they have misunderstood what they have observed. Emulation provides all of the advantages that can be imagined from owning and using a system before it is actually created; a deeper knowledge of its reactions and a
more thoroughly tested control system.
EMULATION TECHNOLOGY
A standard analytical simulation model will contain a representation of the physical system or systems involved and the logical processes controlling the model. An emulation model replaces at least some of this control logic with some or all of the actual control system. In order to do this, the model must be able to communicate with the control system and
respond to it in a timely manner. In some cases it is possible to include control functions within the model executable by compiling them together. More often the control system is monolithic and an interface protocol has to be established between it and the model. Initial work by Coca-Cola Enterprises (CCE) [1 - Hodgson and Katz, 2000] to emulate a bottling
line was done using the Model Communications Module™ (MCM) of the AutoMod™ simulation product. At that time MCM contained sockets technology, enabling CCE to send and receive C structures or character strings between the model and their control system. General Motors implemented a training emulation using Dynamic Data Exchange (DDE) and ActiveX has been employed in other situations. These communication technologies have made way for Object Linking and Embedding (OLE) for Process Control (OPC) [2 – OPC Foundation, 1996], the result of a close collaboration between many manufacturers of control equipment in response to an industry demand for a standard way of accessing controls data. All manufacturers conforming to the various OPC specifications maintain software servers that connect with the manufacturer’s proprietary hardware. Software clients built to the corresponding OPC specification can connect to one or more of these servers and readily access and change the status or value of the various control devices. Whereas previous to the existence of the OPC standards developers would have to buy or develop and maintain drivers for many different control devices from a multitude of suppliers, now the connection task is greatly simplified.
SIMULATION PRODUCT REQUIREMENTS
In order to be useable for material handling system emulation purposes, a simulation product has to have
certain characteristics.
Modeling flexibility
The first of these is a degree of flexibility sufficient to allow the user to create a “hybrid” model where the control system to be verified provides the logic for a part of the model and the simulation product takes care of the rest. To illustrate this, consider a system comprising a fleet of automated guided vehicles (AGV's). It may be of interest to test the functionality of the control system that tracks the position and status of the AGV's in order to control which vehicle picks up which load and takes it where. It is probably taken for granted, however, that the vehicles’ on-board logic will reliably prevent collisions, so this functionality is unlikely to be emulated. A generality arises here; emulation is more likely to be useful for control system modules that are project-specific, rather than standard or widely applicable.
A 3D world view
In all situations where the system to be emulated includes physical movement systems and the load dimensions are of importance, it is a fundamental requirement that the model be in real 3D and to scale. Without this, conveyor transfers cannot be accurately represented or conveniently modeled, photoeyes cannot be blocked and cleared as they are in reality and the emulation loses credibility and transparency.
A low level of abstraction
The level of abstraction necessary to create the emulation should be as low as possible – a software construct called a photoeye should behave in an identical manner to the real object of the same name. The properties that each representation of a mechanical device has should also reflect reality – so conveyor sections have a speed, a width, and a type (accumulating or non-accumulating), a motor can be started and stopped, autostops can be up or down, etc.
A precise understanding of time
Simulation products use various methods to incorporate the concept of time; some progress in tiny steps whilst others use the more accurate concept of event lists. In this latter case the simulation will advance from event to event, creating further events for the current and future event list as appropriate. With graphics turned off, the model will execute as fast as the processor can calculate and update the implications of each event. With graphics turned on, the user can speed up or slow down the animation, but in standard usage the visualization is also affected by the amount of logical calculation being done at each instant. In order to be realistic an emulation model must run at exactly the same speed as the control system, assuming that this system either contains time delays or is based on a scan cycle, such as programmable logic controllers (PLC's).
Initialization
During the initialization of the model it is connected to the server or servers which act as access points to the various control devices. Each device is explicitly referenced at this stage. The user can subscribe to changes in the values of groups of items, which triggers the execution of a message handling function within the model. The model can also explicitly request data during execution.
Transmission
When events occur within the model (such as products blocking or clearing photoeyes, bar codes being read, etc) messages are sent to the control system. Bit values can be changed; strings can be compared – in exactly the same manner that the real system will communicate to its control system.
WORK TO DATE
Following on from the success of the sockets technology contained within MCM, Mitsubishi of Japan showed an interest in developing a proprietary link to their control equipment. This was achieved by compiling their function code with the AutoMod model, from which direct calls could be made to the control devices. For reasons of portability, real PLC devices can be replaced by soft PLC's, which are software equivalents with identical properties to their physical counterparts. To demonstrate the principals of operation of the Mitsubishi project a sawtooth merge model was built (Figure 1).
Figure 1: The Mitsubishi project, showing the ladder logic controller in the background and the AutoMod sawtoothmerge model in the foreground.
Implementing OPC in AutoMod
In order to test the feasibility of using OPC to implement emulation, AutoSimulations began by developing a Visual Basic version of an OPC client.The OPC Foundation specifies two types of clients and servers – either implemented in Visual Basic or in C/C++. The advantage of the VB implementation is speed of development. The VB OPC client is
Figure 2: The Visual Basic implementation of the OPC client
implemented as a stand-alone utility (Figure 2) which connects an AutoMod model to an OPC server. Models can be connected to local servers or servers located anywhere on a network. Once the concept had been satisfactorily proven the full implementation of OPC as an integral part of the simulation product was undertaken. This implementation in C++ offered several important benefits; the most important of which was speed of communication. This gain in speed was not only due to the differences in performance between VB and C++ but also due to the fact that by communicating directly from the model to the OPC server, the model effectively becomes the OPC client. This removes a layer of communication that had previously existed when the model communicated with the OPC server through the VB OPC client. This implementation now takes the form of functions that are called from within the model, which operates in exactly the same way as described earlier. A further important reason for implementing the OPC functions within the model is that this approach enables the use of AutoStat, a utility to create and execute batch runs and collate the results.
FUTURE DEVELOPMENTS
Emulation as described in this paper is gaining in popularity as a result of tighter schedules, decreasing profit margins and a need on the part of the client to get more value for money from a large capital investment project. In order to carry out this kind of project, it is currently necessary to create a team comprising simulation and controls expertise. There exists an opportunity to create a vertical application aimed at those controls groups where emulation is required for projects which are solely PLC-based. Development is currently under way to provide a rapid development tool for emulation models that can be used by controls departments with no simulation experience or training.
CONCLUSIONS
The emergence of the OPC specifications and their de facto widespread acceptance in industry has enabled the development of an emulation tool of great value in a variety of industries. Although this paper has concentrated on discrete event material handling systems in order to illustrate the subject, it should be mentioned that wherever there are control systems that need to be installed on site, emulation for commissioning would be a potential source of savings. The advantages to be had by joining 3D models to real control systems are just beginning to be appreciated in industry and there remain many opportunities yet to be seized. It is to be noted that many systems that are profitably emulated would never be considered good candidates for simulation due to the relative simplicity of their flows.
REFERENCES
1. Hodgson J. and Katz M. 2000, “Using a Portable Simulation Structure with Emulation for Offline
Testing”. In Proc. AutoSimulations Symposium 2000 (Salt Lake City, USA, June).
Cindy Schiess
Simulation Assistant Group Manager
Design Systems Inc.
Farmington Hills, Michigan
ABSTRACT
Various methods for integrating area models into a plant-wide or larger scope model will be discussed. These methods should prove useful in all industries. |
|
INTRODUCTION
Not very long ago, simulation models were done for individual areas of a facility and no one considered incorporating all of the area models into a single simulation model. Hardware and software restrictions did not allow it due to size and speed. Over the years advances in hardware and software capabilities have allowed larger and more complex models to be produced. Today’s technology allows us to have an entire plant simulation run on a PC platform in a reasonable amount of time.
There are several methods that can be used to integrate area simulations into a plant wide model. These Large Model integration methods are:
Data Stream Connections
Model Communications Software Connection
Marriage of Models
DATA STREAM CONNECTIONS
When detailed models have been produced for two or more areas of a plant, they can be connected by having the upstream model produce a data file to “feed” the downstream area. This is the quickest, however, the least accurate method of integration.
The problem with this method is that there is no cause and effect experienced in the model; i.e. the actions of the 2 nd (downstream) model can not effect the results of the 1 st (upstream) model. For example, the shortage of space in the 2 nd model will not effect the delivery of a part from the 1 st model. In reality, the 1st area would be blocked potentially decreasing throughput and/or preventing the return of carriers/pallets/etc. to the beginning of the system. This effect would not be reflected using this method of incorporation.
MODEL COMMUNICATIONS SOFTWARE CONNECTION
This was enabled through the development of the Model Communications Module written by AutoSimulations.
This method would be most beneficial when models are written by two or more simulation sources and it is not desirable to pass the complete model from one to the other. With this method it is possible to only pass the executable and not pass the logic that goes with it.
The model communications code would have to be developed by each of the suppliers independently with close communications to coordinate the information which is passes from one model to the other.
Currently this is not our preferred method of model integration. This method has a slower run time as compared to model marriage while accomplishing the same level of detail. We attribute this to the infancy and lack of experience in using this feature. We intend to continue to pursue this method as a viable alternative as we see its potential. ASI has been working with us on this and have been very responsive to our needs.
MARRIAGE OF MODELS
We have been using this method successfully for a number of years. We have successfully integrated entire automotive assembly plants from the beginning of the Underbody Line in the Body Shop through the end of the Final Line in the Assembly Shop.
The individual areas (e.g. Body, Paint & Assembly for an automotive plant) are developed simultaneously by independent modelers. Even though they are independent, they do stay in close communications with each other and follow naming conventions to assure unique names for all entities.
After all areas have been tested independently for accuracy and feasibility, the models are “Married” into one common model. This allows the interaction between shops to be evaluated. During this model marriage we build in toggles to be able to run them independently or combined. This is very helpful to keep the plant-wide model intact while having to go back and experiment with a modification in one area.
This is still our integration method of choice when we have produced all of the individual models to be combined. This choice is based on speed of execution and ease of use.
SUMMARY
There are benefits to be gained from combining area models into Plant-Wide models. They can be accomplished with minimum amount of effort and time. The method of integration that is to be used is dependent on the time available, the information and models that are available, the level of detail required.
BIOGRAPHY
Cindy Schiess, Simulation Assistant Group Manager, joined Design Systems Inc. in 1988. Cindy holds a B.S. degree in Industrial Engineering from the University of Wisconsin – Platteville. She has 17 years of experience in the engineering field and 16 of those have been spent in simulation.
APPLYING AUTOMOD'S CONVEYOR ENHANCEMENTS
Mike Allen & Steven Finnesey
Durr Automotion
Broxell Close
Warwick CV34 5QF
UK
ABSTRACT
Recent releases have brought a wealth of powerful new features to AutoMod in general, and to the Conveyor and Power & Free movement systems in particular. However, to make the most of these enhancements requires a different modelling approach to that used for earlier versions. The benefits of adopting both the new features and the new style are enormous:
· Reduction in size and complexity of control logic.
· Shorter development times.
· Easier model maintenance.
· Fewer AutoStat Factors required.
This paper employs a simulation study, of a new paint shop at Jaguar Cars Ltd.’s Castle Bromwich plant, to demonstrate how to realise these benefits. Samples of control logic, taken from versions of the model before and after the introduction of AutoMod 8.5 (the release in which these features first appeared), help to illustrate the different modelling approach adopted.
In a more general sense, the paper should prove of interest to modellers faced with accurately representing real-life PLC logic and associated control devices.
INTRODUCTION
The Facility
Jaguar Cars Ltd., part of the Ford Motor Company’s Premier Automotive Group (that additionally includes Aston Martin, Lincoln and Volvo), produces an internationally respected range of vehicles in the luxury car sector, under the Jaguar and Daimler marques.
Their main production sites are all located in the UK: at Castle Bromwich in Birmingham, and at Browns Lane in Coventry. The former provides body-inwhite (BIW) and paint facilities and the latter supports trim & final assembly operations. For the benefit of those unfamiliar with the automotive industry, these are the three primary manufacturing processes, linked as indicated by Figure 1.
Figure 1: The Vehicle Manufacturing Process
The body-in-white process welds pressed panels into body shells and sub-assemblies such as doors, bonnets (hoods) and roofs. During final assembly, each painted body receives an array of additional components, including seats, engines, wheels and CD players.
In purely practical terms, painting cars protects them against rusting and corrosion. However, the paint finish also has an aesthetic contribution to make – particularly so in Jaguar’s marketplace.
The paint shop process is long and complex. At Jaguar, it consists of the following stages:
· Pre-Treatment, Phosphate & Electrocoat. Grease and contaminants, accumulated through the body-in-white process, are removed. A coating of zinc-phosphate crystals and a Allen and Finnesey protective paint base-layer then seals each body against corrosion.
· Seam-Seal & Under-Seal. An application of plastic sealant to panel joints protects them from water intrusion.
· Primer. Each body receives two separate undercoats of colour-matched primer paint, named Primer 1 and Primer 2. These add depth to the final paint finish.
· Basecoat. This process applies the final, coloured paint layer, and can introduce a metallic or pearlescent finish to the body.
· Clearcoat. An application of clear varnish protects the delicate basecoat layer and gives the body a high-gloss finish.
· Inspect & Polish and Repair. A meticulous inspection is made of each body to check for blemishes and defects. A small percentage of bodies receive rectification, undertaken in Spot Repair booths.
· Wax. Finally, a coating of wax helps protect the paint finish from the elements.
The new paint shop, located at the Castle Bromwich site, replaces an existing twenty-year-old Durr facility, and is located in the same building. Space restrictions have constrained installation and commissioning to three phases. As each phase is completed, decommissioning of the replaced section in the previous shop makes room for the next phase.
The original system utilised a skid-based conveyor system. Bodies rest upon carriers known as skids and progress via a variety of conveying systems such as powered roller beds, lifts, turntables and slatted-chain conveyors.
At the time of the AutoMod 8.5 release, Phase I of the new paint shop was installed and running. This phase took the form of an inverted power & free (IPF) conveyor system, servicing all processes from Primer 2 through to Wax, inclusive.
Phase II would replace all processes from Pre-Treatment through to Under-Seal and Phase III the remaining Primer 1 process. The details for Phases II & III had yet to be finalised, but the conveyor systems employed would be skid-based rather than IPF.
The Inverted Power & Free (IPF) Conveyor System
Power & Free conveyor systems are driven by individually powered, continuous loops of chain to which dogs (hooks) are attached at regular intervals. The distance between successive dogs is termed the dog-pitch.
Loads travel around the system on carriers. Jaguar’s carriers each have three, inline, hinged trolleys that run along tracks parallel to a single chain. The second and third trolleys support a mounting for a body. Unlike conventional power & free conveyors that suspend carriers beneath the conveyor, an inverted system drives carriers above the conveyor.
Each carrier’s leading trolley is fitted with a bar that hangs at the same level as the dogs. When a dog passes by, the bar engages it and the carrier is towed behind. This type of trolley is termed a Dog Magic trolley. If the bar disengages its dog, then the carrier stops, whilst the chain continues to move.
The following devices control the flow of carriers:
· Programmable logic controllers (PLC’s). These real-time computing devices handle the operation of the conveyor system.
· Autostops. Under instruction from a PLC, an autostop can delay or release a carrier, controlling accumulation.
· Limit switches. These devices inform the PLC when the leading trolley of a carrier has reached a given point on the conveyor.
· Readers. Carriers have a metal bar code that is scanned by these devices to uniquely identify carriers to the PLC.
· Track switches. These are similar to the points on railway tracks, sending carriers straight on or diverting them onto a new chain.
· Chain-to-Chain Transfers. These transfer carriers to a new chain.
Autostops delay carriers by using an angled blade to lift the bar of the Dog Magic trolley above the height of the passing dogs. The autostop releases the carrier by retracting this blade.
The second and third carrier trolleys are fitted with a similar, non-retractable blade. When a moving Applying AutoMod's Conveyor Enhancements carrier collides with the trailing trolley of a stationary carrier, the former will detach from the chain and stop. Carriers stopped in this fashion are able to resume travelling once the carrier in front has moved on.
Normal accumulation (Figure 2) occurs when the leading trolley of a carrier encounters the third trolley of a previous carrier. Bias-banking accumulation (Figure 3) occurs when the leading trolley encounters the second trolley of a previous carrier (with the third trolley diverted to a separate path). The accumulation pitch is the distance between two successive, accumulated carriers.
Figure 3: Bias-Banking Accumulation
There are two distinct types of IPF conveyor chains: process chains, and delivery chains.
Whenever automated or manual processes involve moving bodies, process chain is used. In order to provide a degree of positional control in the former case, and for health and safety reasons in the latter,accumulation cannot occur; the motor of the process chain is stopped instead. The required rate for the process governs the speed of the chain. For this reason, process chains are also referred to as slow chains.
Delivery, or fast, chains transport and store carriers between processes. Accumulation can take place, but only behind carriers held at appropriate auto-stops. Carriers cannot accumulate on slopes, or across track switches or transfers. If manual or automated processes affect a stationary body held at an autostop, then only that body’s carrier can accumulate there. To minimise travel time, delivery chain speed is relatively quick.
The Simulation Model
Back in 1995, Durr Ltd. used a simulation model, developed with AutoMod 7.7, to support their bid to build Jaguar’s new paint shop. This model served primarily as a tool for visualising the layout and appearance of the proposed facility.
Once Durr had won the $100M contract, the model underwent further development and refinement. Specifically: to model the proposed control system, test alternative control rules, incorporate operator shift and breakdown patterns, reflect the detail changes made during implementation, and to resolve problems identified during the course of the contract.
The model has proved itself many times. It has highlighted, and helped to eliminate, a number of issues. Jaguar invested in an AutoMod run-time licence to allow their own engineers access to it.
By the time AutoMod 8.5 became available, with only Phase I of the installation modelled, much of the control logic had become complex and unwieldy. This created numerous difficulties:
· It was becoming harder to follow the meaning of the existing logic.
· Bugs became more frequent and more difficult to trace.
· The time taken to resolve process and control logic problems using the model was increasing.
It was clear that AutoMod 8.5 provided facilities that could simplify the Phase I control logic, and provide numerous other advantages, but only if the logic was re-written. This is not a decision that one takes lightly! The old adage, “if it ain’t broke, don’t fix it”, applies to software more than to most things. Since release 8.5 supported the logic developed with earlier versions, it was debatable whether changes needed to be made at all.
There was also a problem with migrating this new release: the model employed some C functions that relied upon internal AutoMod library routines. For instance, the model contained C source code that controlled the stopping and starting of conveyor sections. As often happens with new releases, the specification of these internal routines changed, and this C code no longer compiled.
However, on balance, AutoMod 8.5’s advantages significantly outweighed the disadvantages. AutoMod provides a built-in movement system to support the modelling of power & free conveyor systems and this was adopted for the Phase I simulation model.
MODELLING POWER & FREE CONVEYOR SECTIONS
AutoMod provides a built-in movement system to support the modelling of power & free conveyor
systems and this was adopted for the Phase I simulation model.
Two AutoCAD drawings, showing the upper and ground floors of the proposed paint shop, provided the basis for the conveyor layout. A complex process involving IGES files, ACE and numerous Perl scripts, developed by the authors, eventually produced all of the required conveyor sections.
Once the conveyor sections had been created, it only remained to configure them with the appropriate engineering data. The remainder of this section outlines how this was done using “traditional” methods (using AutoMod release 8.2 and earlier) and “improved” methods (AutoMod 8.5 and later).
Traditional Conveyor Section Modelling
Originally, AutoMod provided a single set of defaults for all conveyor sections within a single movement system. Since delivery chain is both the most common type of conveyor, and the most consistent in terms of configuration, the relevant system defaults were set as indicated in Table 1.
All delivery chains, with the exception of a single bias-banking section that has a different accumulation pitch, inherit these system defaults.
However, this implies that all process chain, and the single bias-banking section, must be configured manually by editing each section and entering the appropriate attribute values. In addition, should the attributes of any chain need modification, then the affected chains would need to be reconfigured manually.
To illustrate some of the drawbacks with this system, consider setting up AutoStat to experiment with the dog pitch on all oven chains. Since the model has four oven chains, four factors are required, one for the fixed interval spacing of each chain. Ideally, only one factor is desirable since all oven chains should have the same dog pitch. This causes problems:
· Someone setting up an experiment in AutoStat may not know about the relationship between these factors. There is then the danger that the factors do not share the same value in a given run.
· AutoStat now has four factors to track instead of one. The performance of AutoStat degrades with
each new factor.
AutoMod handles each section individually. However, in practice, it is possible for a number of sections to be physically part of the same chain. The implications for such sections are that they should be guaranteed to have the same configuration and if one section stops, all should stop. It is not possible to guarantee the former, and the latter is difficult.
There are a number reasons for stopping and restarting chains:
· To model the impact of breakdowns.
· To model the impact of shifts.
· To prevent accumulation on process chain.
All sections belonging to a single chain need to be stopped and restarted individually.
Improved Conveyor Section Modelling
The current AutoMod release still provides a single set of defaults for all conveyor sections within a single movement system. The unadventurous are free to continue working in exactly the same manner as before, however there is now a better way.
Section Types allow definitions for specific types of chain to be defined. Furthermore, these definitions can be arranged in a hierarchy so that the characteristics of each type can be inherited from a more general, parent type. At the top of the hierarchy is the DefaultSection, the section type from which all other types are derived.
Figure 4: Conveyor Section Type Hierarchy
Figure 4 shows the conveyor section hierarchy used for the Jaguar IPF system. The DefaultSection is configured as shown in Table 2.
Since there are two basic types of chain, a new section type is created for each: DeliverySection for delivery chain and ProcessSection for process chain. Each of these types inherits its characteristics from DefaultSection. Each section type is then configured to reflect the characteristics common to all chains of that type.
A section type is defined for each individual delivery chain; each section belonging to a specific chain will be set to the section type of that chain. Each of these types inherits from DeliverySection, but specifies the motor (see later) used to drive the chain. Chain 2 has a bias-banking section that requires a shorter accumulation pitch, so a section type derived from Chain2Section is defined with a stopping/moving space of 2.814m.
There are three types of process chain distinguished by dog pitch: booth (1.8288m), oven (1.5240m) and manual (3.3528m). One further distinction is that manual chains need to be stopped when the operators’ shift ends, whilst booth and oven chains (chiefly automated processes) continue to run.
For brevity, only the hierarchy of booth sections will be described in detail. There are two types of booth section, Primer 2 and Colour, distinguished by section velocity – Colour chains run slightly faster than Primer 2 chains. There is a single chain for the Primer 2 booth but three for the Colour line, each having a unique motor. Consequently, a separate section type is required for each Colour chain.
There is now a conveyor section type for each section in the model; there is no need to configure individual conveyor sections beyond specifying their type.
The benefits of employing section types are many:
· It is possible to create AutoStat factors from the characteristics of Section Types. So for example, it is possible to experiment with the value of the dog pitch on all oven chains using a single factor.
· Changes affecting more than one section can usually be made by editing a single section type, rather than the individual sections. For example, if the velocity of the Inspect & Polish lines is changed, a single edit to the configuration of the InspectPolishSection is required.
· Section types can be used with the new section procedures and functions. This allows logic to be written that can be applied to all derived sections.
Sections that are physically part of a single chain can now be synchronised more easily. Release 8.5 introduced the concept of a conveyor motor, as well as motor types. Motors can be stopped using the take down action, and restarted using the bring up action. Furthermore, when a motor is stopped, all sections that employ that motor stop too.
For example, delivery chain 4 appears as six sections in the model. Given a motor, called Chain4Motor, and a section type that uses this motor, called Chain4Section, then the individual sections merely need to inherit from this section. If this chain breaks down, then taking down the motor will stop all of the sections. Bringing the motor back up restarts them.
Note that once a motor has been created, it needs to be included in the definition of its chain’s section type.
In the model, the motors themselves are derived from a hierarchy of motor types as illustrated in Figure 5.
Since motors do not have any characteristics, these types cannot inherit characteristics and do not need to be configured. The hierarchy is useful when motor functions are taken into consideration.
PROGRAMMABLE LOGIC CONTROLLERS
In order to accurately model any automated system, it is important to understand how the real-life system is controlled. AutoMod is actually capable of making decisions far more complex than is possible in a shop-floor control system. For example, the attributes of an AutoMod load or vehicle are always available, whereas a PLC is often ignorant of which carrier it is dealing with, never mind the contents of the carrier.
Similarly, there are details present in the PLC control software that are often overlooked by the modeller, to the detriment of model accuracy.
Two PLC’s control this conveyor system. These realtime computers repeatedly execute the sequence of events, termed a scan, illustrated in Figure 6. PLC memory is organised into registers. Discrete (Boolean) registers take up a single bit of memory, whereas integer registers are two bytes. Larger data types, including floating-point values, can be stored in multiple integer registers.
Figure 6: PLC Execution Sequence (Scan)
Two PLC’s control this conveyor system. These realtime computers repeatedly execute the sequence of events, termed a scan, illustrated in Figure 6. PLC memory is organised into registers. Discrete (Boolean) registers take up a single bit of memory, whereas integer registers are two bytes. Larger datatypes, including floating-point values, can be stored in multiple integer registers.
PLC’s are programmed using ladder logic, so-called because a program visually resembles a ladder. Each rung of the program is a list of conditions, dependant upon the state of specific input and memory (PLC internal) registers, for an output or memory register to be set. The PLC evaluates every rung in the program on each scan.
The final step is for the PLC to examine each output register and set the corresponding output device to Applying AutoMod's Conveyor Enhancements the same state. For example, an autostop may be instructed to open, releasing its carrier and a track switch may be sent to its divert position.
This whole process repeats numerous times each second. Unlike an AutoMod simulation, which maintains the status of a model and changes it with each event, a PLC has to refresh its copy of the status repeatedly. This fundamental difference in operation can be significant.
PLC’s avoid storing status information. When they do, this information is not relied upon. There is always a danger that the PLC’s version of the status information is not the same as the actual state of the facility.
... ...