|Home | Articles | Forum | Glossary | Books|
The difference between the firms that are successful and are not successful in implementing robotic automation on the factory floor lies in the clarity of the overall definition of what the company wants to do. That there will be compromise in most instances where the budget won't cover everything you want to do is accepted.
Assuming that the budget looks realistic relative to the system content and capability, and the ROI is acceptable, the success factor is again a function of how well the specification is defined. Specification in terms of this section will be called the scope of work. The scope of work is the working document that establishes the rules around which the builder, whether internal or an outside system integrator, and the user, will base all future discussions.
All monies, time schedules, and metrics of the project are tied to the details outlined in the scope of work. Imagine the challenge in managing the expectations of the user, or what the supplier thinks needs to be delivered, if an ill-defined scope of work was the working document that both parties were working from. The scope of work does not need to be a 30-page contract like that used for a new house mortgage, but it has to have some very basic ingredients that define the user's needs and requirements, as well as rules for acceptance of the system, and ultimately paying the builder for the system content to which they thought they were designing and building.
This section will provide three examples of scope of work from three different application types. Hopefully, this section will be useful as a guide for developing the scope of work for your project.
A well-defined scope of work is certainly important when the robot system is being built internally, and it is even more critical when the user purchases a system from an outside source. The value of any investment is very important to any firm, not only for the dollars going out to buy the system but also for the value of the system when delivered onto the shop floor. When it comes to money and scheduling, an ill-defined scope of work is a problem. The situation comes down to sorting out a series of assumptions and hearsay about what people thought they heard prior to making the investment in the system. The devil is in the details. If there is a detail important to the team, then it must be called out and documented in the scope of work. Arguing over two distinct points of view in terms of an attribute of the project after the projects starts, costs money and lost schedule time, and there are no winners.
Jobs and careers have been lost over such disagreements where a well-defined scope of work could have avoided a great deal of pain if it had been established from the beginning. The scope of work needs to be as black and white as possible, and if there is any gray then both parties understand why and agree to co-manage those assumptions. For system integrators and other builders of robotic systems, the scope of work is the contract from which all deliverables and services are defined in terms of what, how, when, and who. This section will describe two real case-study projects that the integrator and user developed, prior to entering into a contract.
All the effort and preparation from the audit/discovery in identifying risks and unknowns, and validations, are key ingredients to the scope of work formula. The old saying garbage in / garbage out applies here. One does not start from scratch with developing the scope of work, but rather goes through the process outlined back in Section 2, Figure 2- 1. The scope of work is simple to develop if the previous three steps are followed. The process of developing the scope of work is literally filling in the blanks from the data that was collected in the audit/discovery phase. The risks and unknowns defined then allowed the user not only to identify possible cost pitfalls but also to develop a more refined solution that could potentially solve problems. Moving forward in determining questions to answer or unknowns and risks to validate, was important there because the right solution was derived for the optimum cost, and the rules for what the team could live with were agreed upon. Whatever is validated becomes part of the design criteria in the scope of work and the team will have to live with whatever is left over that isn't validated. The flow for a scope of work is as follows:
Introduction that describes the general system requirements, how the system is intended to work, and the benefits of the system to the value stream
Design criteria (everything that is a known requirement, as well as the definition of every aspect of the process)
Definition of the product itself that is being processed through the system
Prints and models
Sequence of operations
Facilities layouts Definitions of user-provided equipment
Electrical, mechanical, or other specifications for equipment in work-cell
Definition of manufacturing process
Definition of the solution
Equipment description and how it will work for each piece of hardware Description of deliverables
Roles and responsibilities of each team member (whether Key requirements for the system internal or if project is built by outside vendor)
Throughput Expectations of equipment performance
Definition of the state of the product incoming and outgoing at each step
Key assumptions for the system
Setting the rules about changing project parameters
How communication will be set up in terms of reporting
How reviews of progress relative to design and equipment runoff will be managed
Definition of "what is a good part"
What validation is required for the system floor, installation requirements system
Training, spare parts, manpower to support system on shop
Schedule of all tasks to design, build, validate, and install
The length of the scope of work document will vary. Quality not quantity is most important.
Defining Elements of the Scope of Work
The purpose of this section is to provide some definition regarding the key elements of a scope of work. The aforementioned outline is simply a suggestion. The two examples in this section following this section are formatted differently, even though they both serve as a scope of work. The scope of work should be kept as simple as possible. What is interesting is that companies now feel that their specifications need to be massive volumes of details regarding hydraulics, pneumatics, electrical standards, formatting for drawings, and the list goes on.
Companies that send volumes of specifications will often be charged a premium for the simple reason that the group evaluating the program has to sift through all the documentation. The content and clarity of the scope of work drives the success of the program.
However, there is no proportional relationship between the amount of documentation generated and the level of project success. In the end the system has to work on the shop floor, with shop floor personnel.
Of the important elements of the scope of work, the first section is the introduction, which should include the following elements:
Titles of supplemental documentation that is included with the project. The documentation could range from ergonomic specifications to electrical standards, and metrics for acceptance criteria
A generic overview of the project and perhaps where it will
Specific goals and benefits obtained as a result of the project be installed implementation
The next section is the heart of the scope of work. The design criteria will encompass all present and archived information that the user knows and requires concerning the robotic system. In the example later on, where a scope of work for robotic finishing of cast iron cylinder heads is examined, the criteria focuses on all the requirements for the project but does not go into speeds and feeds, tools, or how the process will work. That effort is part of the engineering phase of the project. The design criteria are meant to establish the rules for the project from which the engineering will be designed. These criteria are not meant to be an editorial, but rather should state the known facts about what is known and understood to be true from the user's perspective, and what the user requires of the system. The needs of the design criteria must not be confused with how certain aspects of the system need to work.
The description of deliverables is important, regardless of whether the firm is building its own system or purchasing a system from outside the firm, as in the example of a system integrator. If the firm is implementing the system internally, which many users do, then the deliverables details will enable the team to understand what is going to drive the costs of the project. Usually, it is good to start with hardware. Hardware in my opinion also includes software and the equipment that operates the software, but not the programming or set-up effort. Every robotic system will contain some form of the following deliverables: Robot
Support for the robot (examples include pedestal, base plate, track, boom)
Process tool (i.e. welding torch, gripper, chisel, drill head, grinding wheel)
Hardware to provide work-piece location (examples include conveyor, fixture, pallet magazine, trays, vision, sensors, probes)
Controls that enable communication to be maintained among all the process devices (examples include machinery, process equipment like welders, machine tools, press brakes, injection molding and die casting machines)
Controls that enable interaction with the shop floor personnel.
Human Machine Interfaces (HMI), PC, HMI software
It is worthwhile in the scope of work to agree on what the controls architecture will look like because there are so many ways to accomplish communications, but the range in price can be significant. Decide on the hardware protocol first. Examples could be Ethernet IP, digital discrete 24VDC I/O, Profibus, and Devicenet.
Then decide about whether a PLC is required or whether the robot will be the cell controller. A flow chart should be drawn showing the system controls architecture, with a general schematic showing how information flows between all the devices, as well as designating the communications hardware.
If an HMI is being used, it is helpful to define what parameters should be included within it. Generic information on functions such as monitoring equipment effectiveness, starting the system, and selection of part style are included in the HMI function. A rough outline of what is required is helpful because the cost for an HMI can also be extremely high, and the following details should be included:
Inbound data in terms of the method used to feed the robot system. This hardware may be the same as that used to locate the work-pieces, or additional equipment may be needed. For example, an inbound powered-roller conveyor feeding raw castings to be machined as the inbound, supplemented by a fixed camera over the robot pick location to serve as the enabling tool to find the location and orientation of the workpiece.
Peripherals that enable the robot to perform the process (tool changers, part re-grip stands, and part-qualifying stands are examples)
Peripherals that are important to the system but not necessarily the process. Examples include safety, robot hard-stops to limit robot motion, floor grating to capture coolant in a machine-tending work-cell.
Outbound data in terms of how finished product is transferred out of the cell. The same mind-set here as in the inbound description, but with less emphasis at this point in terms of the work-piece location
Safety systems that follow an internal code or codes that reference the particular region's safety code requirements
Process equipment that the robot uses as part of the process.
This equipment is mainly associated with material removal and welding, where welding equipment, or process machinery like a compliant (a compliant unit is defined as: a mechanism designed to maintain a constant force during a metal-removal process, taking account of such factors as variable surface tolerances) back-stand, are integrated with the robot to do something to the work-piece
Process equipment in situations where the robot loads and unloads the equipment but the two entities do not work together to do something to the equipment. This item can be very long
Other hardware with which the robot will interact within the system, which can be a very broad list. Some common items that come to mind are bowl feeders, bar code readers, WID readers, gages, washers, leak testers, trim presses, etc.
The list above pretty much covers hardware. What remains is the effort needed to design, build, program, and de-bug the system.
Decisions about which parts will be automated, and which parts will be validated as part of the acceptance of the system are important components to the scope of work, and that is why there is a separate section for acceptance criteria. The criteria for acceptance are also important because they provide the last chance to make sure the system works prior to handing it over to the shop floor. It is always best practice to test the system before releasing it to the shop floor because shop floor personnel and management get soured quickly when a brand new system is installed and does not run immediately.
Internal or external engineering resources will be required to implement a robotic system. As described back in Section two, robotic systems are not put together by a single person but by a team of people from varying disciplines. The scope of work helps define the level of contribution of each of these individuals. The underlying point to make here is that, regardless of standards or custom systems, all the aforementioned categories have to have some thought and definition if the system is to work as planned.
The next two sections are examples of two completely opposite systems. One is highly complex and the other simple. The risks, and associated costs are completely polar opposites. What they have in common is that the same exercise of audit/discovery, identifying risks and unknowns, and validation, enabled a scope of work to be created that enabled the user and the implementer, whether or not they were one and the same, to achieve positive results in terms of reliable systems that surpassed levels attained by any manual operation ever.
Scope of Work Example - Robotic Finishing Cylinder Head Line Case Study
The first example is extremely detailed and was developed around a robotic material-removal project. This example can be used as a guide for any application because the same rules always apply for the same scope of work. This section will include additional scope of work examples for additional application types.
The background for this first project example was provided by Foundry Solutions and Designs, an engineering consulting firm working in the foundry industry.
A major foundry was experiencing significant cost pressures globally in producing cast iron engine cylinder heads, for which the finishing process is highly labor intensive and accounts for over 40 percent of the cost to produce the casting. The company wanted to improve finishing operations on six (6) high-volume casting versions, which make up the bulk of present and future production.
The foundry was using largely traditional methods of chipping and grinding, with a mechanized grinding machine as well as hand tools and manual labor, to carry out all the internal and external finishing to the stage where the cylinder heads were ready for heat treatment.
Current plans are to make maximum use of automated machinery, robots, and manipulators, with the joint aims of raising the quality of finishing and removing the need for operators to engage closely in the often arduous and unpleasant work.
The plan is to install a largely automated cylinder head "finishing line" which will take castings from the molding line and deliver them fully finished and inspected to the existing heat treatment furnaces. The section describing the equipment in the solution is omitted here.
Foundry Solutions & Designs Scope of Work
Principle of Operation
The major objective is to finish a range of cylinder heads from shakeout to heat treatment, with minimum manual intervention.
This aim will be achieved by the use of programmed CNC or robot devices, manually-operated manipulators, and special purpose machines, coupled with an automated transport system. Some of the mechanized finishing stations will use specific jigs and fixtures to hold the castings during processing. Attention needs to be given to developing a locating and holding fixture design that is common for all the specified products. If this aim is not economically feasible, then the exchange of locating and holding devices is to be accomplished automatically during cycle time. The entire system will be integrated using Level II controls.
All castings will follow the same general sequence as outlined on the following page:
Gates, risers, over-flows, and selected flash, will be removed
Automatic surface grinding will be used for up to six faces
Hole opening will be used to assist decoring
Decoring will be done by high-frequency, low-amplitude pneumatic equipment
Shot blasting will be done by existing equipment (modified to accept small heads)
Fine finishing and removal of parting fins (not reachable with the large automatic grinders) will utilize robots
Finished castings will be loaded onto pallets and stretch wrapped
With the current molding method (combination of core packages in green-sand molds) some slight variation in the castings and the size of the fins is possible.
The proposed metal removal tooling should be of the "compliant" variety to allow for self-adjustment to accommodate slight irregularities in the castings.
Product Mix and Volume
The finishing line will be designed to process up to six (6) different designs of cylinder head. One style is unique and that is style number one. The second style head has five variations within the family.
The cylinder heads to be processed are:
=== Engine series Quantity/mold Processing Rate
Style # 1 2 24Oihour Style # 2a 1 1 OOihour Style # 2b 1 1 OOihour Style # 2c 1 1 OOihour Style # 2d 1 1 OO/hour Style # 2e 1 1 OOhour
Only one casting type will normally be processed through the system at any one time. The system will be designed to allow a switch to any one of the above six casting types at any time, with no significant loss of production during the transition stage from one type to the next.
Other cylinder head types may be brought into the system at a later date, provided that they conform to the overall dimensions and production rates of the above types. However, any additional locating and holding devices must be changed within normal cycle time.
The entire system will operate as an automatic progressive processing line as shown in FIG. 1. In other words, the line will consist of a series of independent work cells arranged in the sequence of operations required to finish the cylinder heads. The system will be a pull system based on customer orders, and the line will be configured for a batch of one process.
Manual control will be allowed for local start-up, commissioning, and trouble-shooting.
After loading by manipulator at a single loading station, all castings, except for the style-3 heads, will be transported automatically through the system at a rate of 100 cycles per hour, and will be loaded thus:
The style-3 series cylinder heads will be processed two at a time, at a rate of 120 cycles per hour, at each station, on each locating and holding device.
The other five types of cylinder heads will be processed individually.
Every station may not be required for all cylinder head types, and the transport system will by-pass the unused stations with no loss of production capacity.
Provision will be made at certain locations for castings to be removed for intermediate storage in the event of a system failure at any point. The control system logic will also provide the option of running the system out without loading new parts.
Castings removed will be able to rejoin the system after restoration of normal operations.
Casting types and orientation will be automatically identified at each sub-system to ensure that workstation settings are correct.
Access to the shot-blast machines, for loading and unloading will be provided for other castings that are not processed through the automated stations.
Downtime of the cleaning line must not be allowed to interfere with the uptime of the molding line feeding it.
Therefore, the manually-operated manipulators will be available to load unprocessed castings onto pallets that will act as a buffer zone at the shakeout apron conveyor Scrap and waste material removal
Throughout the system, provision will be made for all waste materials generated within the system (sand and metal flash) to be removed and conveyed to the refuse system.
Scrap and waste material removal
Throughout the system, provision will be made for all waste materials generated within the system (sand and metal flash) to be removed and conveyed to the refuse system.
Writing the Right Specifications
A general arrangement drawing has been prepared and will be provided, showing the general layout of the proposed arrangement in the area available at the Mapleton facility.
The proposed layout will include some existing equipment (some of which may be relocated) and some new units. The installation sequence must be designed to cause minimum disruption to the flow of work through this existing section. A drawing has been prepared and will be provided, showing the underground network of conveyors for scrap and waste removal.
Figures 2 and 3 following this scope of work description show pictures of the specific areas to be finished, and the casting finishing sequences, for both styles of cylinder heads.
Gates and risers will be broken off the castings by, two (2) manually-operated manipulators, located alongside the apron conveyor.
These manipulators will also separate the gates and risers from the castings. The gates and risers will be left on the apron conveyor and will fall into a chute at the end of the conveyor, to be taken away by an under-floor system. Where required, special "helper" devices may be installed to assist the operator in breaking off risers or gates.
Castings requiring these devices will be placed on the device with the manipulator, but clamped in the device itself during break-off.
Placement on Castings Transport Conveyor
The transport conveyor system will accept castings from either manipulator and convey them to a casting identification and orientation station. Any casting not conforming at the recognition stage will be diverted to a rejection conveyor where it will be identified manually and redirected into the system or removed for processing in another location.
Castings will be transported automatically using conveyors or robots, to the next processing cell.
Some of the cylinder heads will have core prints that are flashed over, which would impair removal of the core sand. To overcome this feature, hole-opening stations will be provided that will use powered tools to break the flash. These hole opening stations will be either CNC or robotic, and will be housed in noise and emission control cabinet(s) that permit necessary access. They will be provided with appropriate safety interlocks to prevent unauthorized access when in operation. Special devices will be utilized to check on tool wear. Two (2) such stations are required for redundancy.
Each station will be capable of completely opening all the required holes on the castings. These stations will be loaded and unloaded automatically.
Automatic Surface Grinding
The automatic grinders will be designed to completely grind the top surface as presented, and the casting perimeter, including parting lines, core flashing, etc. Each cylinder head will be delivered by the transport system conveyor and placed into the locating and holding device of the grinder. Two (2) such stations are required for redundancy, and they will be housed in noise and emission control cabinet(s) that permit necessary access. The cabinets will be provided with appropriate safety interlocks to prevent unauthorized access when in operation. Special devices will be utilized to check on wheel wear. Each station will be loaded and unloaded automatically.