Below are the first 10 and last 10 pages of uncorrected machine-read text (when available) of this chapter, followed by the top 30 algorithmically extracted key phrases from the chapter as a whole.
Intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text on the opening pages of each chapter. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.
Do not use for reproduction, copying, pasting, or reading; exclusively for search engines.
OCR for page 75
Munitions Manufacturing: A Call for Modernization 5 Controllers INTRODUCTION This chapter defines basic terminology and control concepts and then describes the control needs of the munitions industry, as expressed by participants in the Totally Integrated Munitions Enterprise (TIME) program. It then explains the capabilities and limitations of todays commercial off-the-shelf (COTS) controllers, followed by an account of the ongoing efforts to develop a truly open control architecture and interchangeable components. The last section presents the committee’s assessment of control needs for the munitions industry. An assessment of machine control technologies should begin with a list of the production equipment and processes to be controlled. The manufacturing operations conducted in the munitions industry fall into four broad categories: (1) fabrication of metal and plastic parts, (2) assembly of electrical components, (3) energetics processing, and (4) final pack and load. A list of parts fabrication equipment at the Downey Operations facility of Primex Technologies, a prime munitions contractor, although more up-to-date than government-operated facilities, is perhaps typical (Cary 2000): High-volume turning Multispindle lathes, Multispindle Davenport screw machines, and Multispindle automatic chuckers, Computer numerical control (CMC) machining CMC lathes, CMC chuckers, and Multiaxis machining centers, Precision grinding, Wave solder, Plastic insert molding, Automated finishing, Painting, and Inspection and testing. Appendix C presents operating details and controller requirements for a typical “melt pour” method for processing energetics, as well as another method, the twin-screw extruder. This information was assembled by the TIME program in
OCR for page 76
Munitions Manufacturing: A Call for Modernization May 2000. The only other specific set of machine control requirements for the munitions industry of which the committee is aware is the DOE/OMAC Department of Energy Open Modular Architecture Controller Milling Machine Requirements issued in January 1999 (LLNL 1999). The committee believes, based on presentations by the TIME program, that these applications are representative of the most difficult applications in the munitions industry. Much of the equipment in government-owned/government-operated (GOGO) munitions facilities was installed before the era of electronic controls, with few upgrades since. Control of these types of equipment has traditionally been performed by either CMC or programmable logic control (PLC). It is not unusual for manufacturers to have tens or hundreds of numerically controlled machine tools in a production facility, each with its own proprietary controller. Due to the proprietary content of early controllers, each piece of equipment was an “island of automation,” impossible or difficult to connect to other equipment or to manufacturing information systems. By 1986, control engineers were able to successfully connect together machine tools, measuring machines, wire-guided vehicles, computers, tool gauges, and materials requirements planning (MRP or MRP I) systems, each from a different manufacturer. These pieces of equipment provided manufacturing equipment with basic motion and device control capabilities but typically provided the user with minimal configuration options and had limited communication capabilities. More modern controls that are used to run these pieces of equipment, such as those encountered in modern dual-use or commercial munitions facilities or those that would be used to upgrade government-owned facilities, typically consist of a collection of interconnected software and hardware modules but with more ability to configure the system and more openness in terms of communications capabilities. These modules contain software that implements two different kinds of interfaces. Functional interfaces between the software modules are called application programming interfaces (APIs). Component interfaces used with the APIs allow system integrators to choose modules with the functionality required for the specific application, connect the chosen modules together, and verify that all required system components have been properly connected. Until the last 3 to 4 years, nearly all machine tools were equipped with proprietary real-time controllers with specialized human-machine interfaces (HMIs). Recently, the major suppliers of CMC controllers have provided access to expanded functions of the controllers through general-purpose microcomputer front ends. In addition, proprietary controller manufacturers have been challenged by suppliers of CNCs using microcomputers with real-time extensions to the operating system. INDUSTRIAL NEEDS AND DESIRES At the beginning of the 21st century, the needs and desires of the munitions industry are similar to the needs and desires of much of commercial industry. For instance, TIME believes that numeric control using the Standard for
OCR for page 77
Munitions Manufacturing: A Call for Modernization the Exchange of Product Model Data (STEP), called STEP-NC, could increase the productivity of integrated supply chains in a wide variety of industries. TIME also believes that if industry starts using STEP-NC in a major way, it would be desirable, though not essential, that the munitions industry move to adopt STEP-NC to enable more rapid, cost-effective supply chain integration, especially for purposes of replenishment. Both commercial and defense manufacturing operations would benefit from the ability to provide incremental upgrades, which is a way to increase the useful life of controllers. Further, the ability to add modules would allow the munitions industry to build safety systems into the controls or add them later, as needed. The capability to do model-based manufacturing will potentially benefit most types of industries. COMMERCIAL OFF-THE-SHELF CONTROLLERS Today’s COTS products from companies like Siemens, Modicon, and Rockwell Automation are characterized by three basic similarities: (1) division of PLC logic and complex motion, (2) difficult integration between vendors, and (3) use of the Distributed Component Object Model (DCOM) as an integration standard. DCOM is the de facto standard for communications integration between controller components. As such, it must be examined against the needs, desires, and constraints of the munitions industry. DCOM was designed for desktop equipment. Real time in the desktop world is measured in terms of seconds. DCOM has been heavily leveraged by HMI users to provide easy integration for commercial controllers. The effort associated with object linking and embedding for process control within the controls community has shown the power of the DCOM technology when applied to realistic control problems. The implementation of DCOM still provides challenges to the controls engineer: (1) difficult domain-to-domain integration, (2) possible large-packet-delivery latencies, and (3) large timeouts due to packet failure. Each of these areas is examined below. Difficult Domain-to-Domain Integration DCOM requires that users meet all security requirements on the server machine before they can access it. This means the user must have an account with identical privileges on both the client and server machines. This model works well within a particular network domain but is difficult to configure across domains. In the normal solution, the user is configured as an administrator across both machines, which violates security policies designed to protect the system. This configuration is difficult within a single vendor’s product family, let alone between two different vendors. Domain-to-domain DCOM integration difficulties have, to date, prevented true enterprise-wide integration of control information.
OCR for page 78
Munitions Manufacturing: A Call for Modernization Large-Packet Delivery Latencies Many machinery and process control applications require near real-time response. Communication delays can result in safety hazards or ruined product. DCOM communications are normally transmitted on a company’s ethernet infrastructure. Data loading on the corporate network is highly unpredictable. DCOM’s use in real-time situations requires deterministic bounded response, which is impossible to guarantee when it must compete with unpredictable amounts of additional traffic. There are products, such as high-speed switches, that can help to alleviate possible large-packet delivery latency problems, but they cannot reliably solve the problem throughout an enterprise that may span the globe. Large Timeouts Due to Packet Failure Because DCOM was built on top of object-linking-and-embedding technologies from Microsoft, one of its basic legacy issues is that timeouts of up to several minutes can be caused by a packet failure. A client or server may not be notified of a delivery failure for up to 6 minutes. This characteristic is a major impediment to the adoption of DCOM for critical roles. The DCOM standard has led to major revolutions within the HMI and supervisory-control-and-data-acquisition industries. However, DCOM’s adoption for applications that demand real-time response is limited by its configuration and by the possibility of large-packet latencies and long timeouts. EFFORTS TO DEVELOP OPEN MODULAR ARCHITECTURE CONTROLLERS Concept of Open Architecture There are many interpretations of the word “open” in the machine tool industry. Most controllers sold today are open at some level, but no currently available controller is open at every level. When a control uses some type of standard interface, it can be considered open within the context of that interface in that any software or hardware object that adheres to the standard may be used. Open software generally means a standard library to which everyone has free access. Open hardware generally includes a published input and output schematic diagram that enables anyone to interface to the product. Because open architecture controllers typically consist of both hardware and software, a completely open product offering must contain both open hardware and software. The microcomputer is an example of a highly successful open architecture system. Users can choose from a wide selection of plug-and-play hardware components, such as keyboards, video monitors, and sound cards. A massive number of software products are available from a wide variety of sources. Although these products interact and operate almost seamlessly within
OCR for page 79
Munitions Manufacturing: A Call for Modernization the open architecture framework, hardware and software suppliers are able to retain levels of proprietary technology sufficient to enable a high degree of profitability without impeding interactivity. By eliminating barriers to interconnectivity and interactivity, the microcomputer’s open architecture has enabled huge benefits and cost savings that may never have accrued with more restrictive or closed architectures. Proponents of open architecture controllers believe that similar benefits will accrue from the development and universal adoption of a similar open approach to machine control. History of Open Architecture1 When a few machine tool users and researchers began requesting open architecture controllers in the early 1990s, machine tool builders typically tried to satisfy these demands with microcomputer-based systems. Although they used a general-purpose computing platform, these controllers were no more open than their predecessors. Users remained locked into the original supplier for hardware and software upgrades and functionality improvements, just as most of today’s microcomputer users are locked into Microsoft Windows. It wasn’t that machine tool builders did not want to satisfy the customer. Rather, the demand was extremely small and was predicted to remain small. They also had an overriding concern that by enabling customer access to the controller they would create the possibility of customer error, and the cost of adding the hardware necessary to make a software real-time control loop competitively fast would have significantly increased the cost of the CMC. They feared that inexperienced customers would make programming changes that could cause serious problems and expose machine tool builders to liability lawsuits. “Flexible architecture” controllers available today satisfy most user needs, in that they permit interoperable and interchangeable product selection. They have a clearly defined input and output model at desirable component levels. However, they also require at least one proprietary hardware or software component to function. A high percentage of users do not care about this, but a concern of Open Modular Architecture Controller (OMAC) advocates is that if the manufacturer decides not to support, maintain, or supply the proprietary element of the system, the system could be rendered useless. This concern is especially compelling in U.S. defense manufacturing industries because these proprietary elements are available only from non-U.S. sources. Many motion control card suppliers provide a basic numerical control (NC) front end that they call “open.” It is called open because the interface definitions are provided, so that the user or third-party integrator has full access to the controller’s functionality. In a research environment or in the development of specialty machines, this is a good option. However, this interface definition is only for a specific, limited set of hardware. For example, according to Robert Hillaire of the University of California, Berkeley (Hillaire 2000), OpenCNC from 1 A more detailed history is presented in Appendix B.
OCR for page 80
Munitions Manufacturing: A Call for Modernization MDSI (Ann Arbor, Michigan) satisfies many of the requirements for openness. It has a front-end application programming API that provides access to important process information. However, while it allows the use of a variety of third-party hardware options, OpenCNC does not provide a truly open interface to third-party hardware. Although it provides more choice than typically available, the selection of hardware is still restricted. Only if MDSI provided an API or hardware-drive standard for the system that allowed all hardware manufacturers to develop products that fit the standard, would OpenCNC be a truly open architecture system. Further, to be truly open, MDSI must modularize its software and provide an API for communication between modules. International Efforts Efforts to develop a truly open architecture began in Europe in 1992 with the Open System Architecture for Controls within Automation Systems program. Japan began work in 1994 on the Open System Environment for Controller program. Department of Energy Involvement in OMAC The U.S. Department of Energy (DoE) has often encountered unique problems with controllers. On multiple occasions when designing a new custom machine, Lawrence Livermore National Laboratories (LLNL) has encountered a need to design a new controller. The large optics diamond turning machine (LODTM) is a good example. This machine was designed in 1980 to manufacture the resonator optics for the Air Force’s Space-Based Laser. These were 1.5-meter-diameter optics with surfaces accurate to 0.1 micron. When designing LODTM, LLNL wanted to use a commercial controller but ran into problems. The turning machine has only two axes but uses seven laser interferometers and six capacitance gauges to measure positions on the two axes. Hence, a complex calculation is required at an update rate of 1 millisecond. LLNL sent a request for quotations (RFQ) to commercial CNC manufacturers and received no responses. They were told that the CNC manufacturers would be better off investing their available resources on other, more profitable projects, even if LLNL offered to pay for development. Similar examples could be cited for other DoE facilities. In 1994 the General Motors Powertrain Group (GMPTG) came to LLNL with their Requirements of Open, Modular Architecture Controllers for Applications in the Automotive Industry white paper (OMACUG 1994). LLNL recognized the similarity of its needs. If the automotive companies could drive these concepts into general availability by including them in their RFQs, LLNL would have a commercially available source of reusable, component-based controllers and could exit the custom controller business. With these objectives in mind, LLNL drafted a Cooperative Research and Development Agreement in 1994, which said, in part (Rosenberg et al., undated):
OCR for page 81
Munitions Manufacturing: A Call for Modernization The goal of an open architecture controller is to create an environment, which allows the largest variety of control problems to be solved over a wide range of performance and price. It is NOT to create a single controller, which will be able to solve every possible problem. Rather it is to create a controller architecture, which is sufficiently flexible and scalable, so the reasonable tradeoffs between performance, price, and flexibility may be made by the end user. If this environment is properly designed, it should allow an end user to solve virtually any real-time control problem (within the constraints of hardware performance and cost). In other words, it would allow end users to create a multitude of controller solutions based on a standard environment, paying for extra performance only where needed. These high-level goals remain unchanged today. The goals of OMAC are as follows (OMACUG 1994): Open. Allowing the integration of off-the-shelf hardware and software components in a de facto standard environment; Modular. Permitting plug-and-play of components; Scaleable. Enabling easy and efficient reconfiguration to meet specific needs ranging from high end to low end; Economical. Achieving low life-cycle cost; and Maintainable. Supporting robust factory floor operation (maximum uptime), expeditious repair (minimal downtime), and easy maintenance. In an effort to promote the vision of open control architecture, LLNL teamed with GMPTG and others to develop a set of APIs for an open architecture controller. These APIs (OMACUG 1999) define the environment for solving control problems. Work was begun in 1995 under the auspices of the DoE TEAM program. In a further effort to promote these open architecture control solutions, the OMAC Users Group (OMACUG) was formed in 1997 by the automotive companies and approximately 10 other large end-users. This group has grown to over 200 participants, including Allen-Bradley, Boeing, Bosh, Caterpillar, Cummins Engine, Daimler Chrysler, Deere, Delta Tau, Eastman Kodak, Ford, GE Fanuc, General Dynamics, General Mills, General Motors, Goodyear, Indramat, Ingersoll, Makino, Mazak, MDSI, Microsoft, Monarch, Okuma, Pratt & Whitney, Siemens, and STEP Tools.
OCR for page 82
Munitions Manufacturing: A Call for Modernization Approach to the Needs of Commercial and Munitions Industries In 1996, the General Motors Powertrain Group Manufacturing Engineering Controls Council authored a paper titled Open, Modular Architecture Controls at GM Powertrain (Taylor et al. 1996). This document presented three key strategies discussed in the sections that follow. Math-Based Manufacturing The first strategy involves the use of math-based manufacturing. Following is an excerpt from the GMPTG document (Taylor et al. 1996, p. 10): Math-based manufacturing is one of the key manufacturing strategies at GMPTG. The goal of this strategy is to link mathematical models of product design, casting design, and machining design into a single three-dimensional math model for a particular product such that the math model can be used in the manufacturing processes directly in electronic form. If changes are made in the product design process, appropriate changes in the casting model and machining model will be made automatically to accommodate the product changes. It is necessary to have an agile manufacturing system to support the math-based manufacturing strategy because the manufacturing processes need to be able to take a 3D math model directly and produce the products efficiently. The manufacturing systems also need to be agile to handle the frequent changes in product design. The common control platform at each machine allows a common networking approach for downloading of math data, thus OMAC technologies become one of the key enablers for the successful execution of the math-based manufacturing strategy. GM’s term “math-based manufacturing” is a combination of the precepts of agile manufacturing, integrated product and process development, concurrent engineering, art to part, and many other modern manufacturing concepts. Math-based manufacturing is a major strategy of the TIME program. The part of this strategy that applies to the OMAC is the concept of driving the mathematical model down to the shop floor, commonly referred to as “art to part.” The ability to drive the mathematical model directly from computer-aided design (CAD) to the shop floor offers estimated process planning and manufacturing control savings of between 35 percent and 75 percent (Burleson 2000). It also has supply chain implications. Traditionally, suppliers took the model provided by the prime contractor and separately developed the information needed to drive their process equipment. This requires manipulating the data for each type of process
OCR for page 83
Munitions Manufacturing: A Call for Modernization equipment and each type of control. In going directly from art to part, the supplier would use the identical database to manufacture the product that the prime contractor used to design the product, thereby eliminating some of the intermediate work. This not only saves time and cost but also eliminates several potential sources for error. The OMAC is planning to use the emerging STEP-NC standard as a replacement for the Initial Graphics Exchange Specification. STEP is being designed to address both process information and product information. To that end, an international committee is using STEP to define NC data as a replacement for RS-274. True art-to-part capability has been demonstrated and the controllers are now designed to accept feature-driven STEP-NC information directly.2 To this end, the National Institute of Standards and Technology has funded an advanced technology program to STEP Tools, Inc., titled Model Driven Intelligent Control of Manufacturing available online at <http://www.atp.nist.gov/www/comps/briefs/99014035.htm> with the goal of putting together the toolset required to create STEP-NC data from a standard STEP database and using that to drive controllers on the shop floor. Simultaneously the TIME program is modifying the architecture of the OMAC to accept STEP-NC information directly, without any translations. In this effort, General Dynamics Land Systems will deploy a controller on a Bridgeport mill at the Scranton Army Ammunition Plant (Albert 2000). This approach is intended to benefit commercial industry, DoE, and the Army. Reduction of Control System Development and Integration Time The second strategy is intended to allow for the rapid changeover of manufacturing systems from one product to another. Following is another excerpt from the GMPTG document (Taylor et al. 1996, p. 12): With the pressure on GMPTG manufacturing systems to adjust to the fast changing demands from the marketplace, the time required to design and integrate a control system needs to be greatly improved in the near future. When OMAC-based control systems become more prevalent, most control components will conform to the standard interfaces and become interchangeable (plug and play). Software tools will also be more available to assist control engineers to perform the system integration tasks. The need to train and re-train personnel will be reduced, further reducing the system integration time. One example of a rapid changeover requirement cited by TIME sponsors was a GM example of the need to change a transfer line that makes the 2.8L cylinder heads to one that makes the 4.3L cylinder heads. In the early 1990s. GM 2 This capability was demonstrated in July 2001. The prepublication document postulated this development.
OCR for page 84
Munitions Manufacturing: A Call for Modernization was selling as many S-10 trucks as it could make 4.3L engines. The problem was that the company had invested heavily in the 2.8L engine and had installed transfer lines to build it. Hence, it had excess production capacity for a product that few people wanted and insufficient capacity for the product that people wanted. The production changeover to the new engine required 18 months, an unacceptable amount of time in an era of rapidly changing consumer demands. GM wants to reduce that time on this and other production lines and, according to the TIME program, sees the OMAC as a necessary enabling technology (Burleson 2000). The committee, however, does not believe that this is a valid argument for the OMAC. In the 1970s and 1980s, U.S. CMC makers urged the American auto makers to begin using NC machines to reduce changeover time and cost. They resisted while their Japanese and German competitors went ahead and tried them. The non-U.S. auto makers proved in practice during the 1980s that these benefits were readily achievable with 1980s model CNCs. OMAC technology was not necessary. Even today only a small percentage of U.S. auto parts are made on CMC equipment. The TIME program believes that the situation in the munitions industry is similar to that in the U.S. auto industry. The Army wants to be able to rapidly change equipment from commercial production to munitions production if needed to replenish its stockpile. For companies like GM, to change from building a commercial product to building munitions requires a lengthy changeover of equipment. TIME program participants see the OMAC as a means to help them achieve that goal just as GM sees it as a means to help it achieve its engine manufacturing goal. This doesn’t mean that such changeovers cannot be accomplished without the OMAC, just that it is somewhat easier and probably much quicker with the OMAC’s modular technology (McWilliams 2000b). Incremental Upgrades of Control Systems A third strategy allows easy upgrade paths. Following is a third excerpt from the GMPTG document (Taylor et al. 1996, p. 12): When functional add-ons to a control system, such as sensors, communications, diagnostics, etc., are required, an OMAC-based control system allows the most appropriate technologies to be selected and integrated without relying on specific control vendors to develop custom solutions. These functional add-ons are required to implement what has been referred to as “model-based manufacturing.” In this approach, a model of the process is used to control the process so well that the manufacturer is assured of a good part without dimensional inspection the first time it is produced. Implementation of this approach requires the ability of the controller to accurately measure multiple aspects of the process and communicate these data to the model in real time.
OCR for page 85
Munitions Manufacturing: A Call for Modernization For that, many add-ons can be required, such as process sensors. The model of the process must be implemented in the controller. This is being done today with continuous process controllers in the chemical industry. In the munitions industry, it must be implemented in machinery used to produce batches of energetics and discrete mechanical parts. One of the potential applications for this controller technology is in the mixing of propellants using a twin-screw extruder. The Army has already developed a process for one formulation using simulation. It plans to use that model to control the process in a small-scale experiment. Once it is satisfied with the results, it plans to incrementally scale up the process to full production. All of these efforts will use the identical math-based model developed in the initial simulation, with incremental updates based on increased experience with the equipment and process. The TIME program has also demonstrated the ability to remotely monitor the process, which is important for safety reasons. TIME implemented a hard-wired version of the monitoring system in 1999 but encountered problems and expenses in attempting to modify the existing controls. TIME believes that the use of OMAC would make these modifications quicker and less expensive. Another important aspect of open architecture controls is the ease of adding sensors and process diagnostics. When working with energetics, safety is of paramount importance. DoE has succeeded in adding sensors and process diagnostics by means of heavy modifications to an existing controller. However, that controller vendor has gone out of business, and the DoE facilities have not been able to replace the existing controllers with commercial controllers that can perform the needed functions. To maintain the capability, new open architecture controllers are being installed but with similar difficulties and similar modifications required. These same issues exist in the munitions industry. OMAC is intended to allow the addition of appropriate technologies as needed and reduce the risks associated with the availability of vendor support. A working group of OMAC was formed to develop a specification that defines an intelligent closed-loop controller environment. This environment is to incorporate open architecture concepts and support application portability at the source level, interoperability of modules, and extensibility of controller functionality. The environment is intended for system integrators and applications software developers who will specify standard APIs for open architecture controllers. This working group used the requirements and initial API definitions from the DoE TEAM program as the basis for its work. In defining this architecture, one of the overriding requirements is allowing one component to be swapped with another, in other words, allowing one implementation of a module to be replaced with another implementation. This requires that the APIs specify how the results of a computation are accessed but not how the calculation is carried out. The original OMAC requirements specified that the controller be open, modular, and scalable. The openness and modularity requirements were addressed by breaking the controller into several replaceable pieces, defining the state behavior for those pieces, and specifying their APIs. “Scalability,” which was defined as enabling easy and efficient reconfiguration to meet specific
OCR for page 86
Munitions Manufacturing: A Call for Modernization application needs, from low to high end, has several dimensions to it. One of these is the ability to extend the APIs of the modules for more demanding, unanticipated needs, while still allowing backward compatibility with existing components. This was addressed by treating the module APIs as object-oriented entities, that had no implementation. Inheritance can be used to extend any given API and, therefore, any given module. A software component, for purposes of OMAC, is required to implement one or more well-defined API sets, have a well-defined state behavior (which is reflected in the individual API sets), and be easily integrated into a controller or exchanged with another compatible component. Ideally these components could be shipped as binary code, rather than source code, allowing software producers to protect their proprietary knowledge. The APIs, however, exist only as an unproven document (OMACUG 1999), until a reference implementation is built that proves that they work. TIME intends to build a reference implementation controller using the OMAC-defined APIs and make it available to controller vendors as a starting point for their own commercialized implementations. TIME has implemented a reference implementation of an extensible machine tool controller using Java. This controller is based on the OMAC module APIs and component APIs. In addition, TIME has implemented rudimentary integration tools that take advantage of the component APIs, generating application code and checking for system consistency. The committee believes that Robert Hillaire perhaps best summarizes the state of worldwide open architecture development when he says that “while influential groups are developing the foundation for a more standard controller, they haven’t yet created a useful standard for an open architecture controller” (Hillaire 2000, p. 88). Munitions Industry Needs and Commercial Controller Capabilities The TIME program selected two process control examples, that they believe to represent munitions industry challenges that can be met only by using OMACs. These are (1) the melt pour process at the Iowa Army Ammunition Plant, and (2) the use of the twin-screw extruder to process energetics. These examples are presented in detail in Appendix C. The committee has evaluated the control requirements for these processes, as presented to the committee by TIME program participants, and determined that OMAC is not necessary for these applications. The best solution would probably be a Pentium III microcomputer interfaced to a programmable logic control. (It is even possible that a high-end PLC would do the entire task.) Another good approach, although more powerful than needed, would be a commercially available OAC. This would cost only a fraction of the price of bringing OMAC to commercial reality; could be achieved about 2 years earlier; and would have commercial technical support such as manuals, updates, training classes, and technical service staff all over the country.
OCR for page 87
Munitions Manufacturing: A Call for Modernization The TIME program and the committee agree that a superficial market study without in-depth technical analysis of COTS motion solutions can lead to a false sense that the market is full of truly open control products. The TIME program has identified a set of munitions industry control needs and desires, some of which they believe challenge COTS definitions of “open.” The list, along with committee comments, follows: Support for model-based control—The committee believes that any CMC with a disk operating system (DOS) partition can accomplish this. Ability to close loops throughout the controls architecture—The committee believes that this capability is available commercially. High-speed deterministic communications between facilities—High-speed point-to-point communications are becoming commonplace. In addition, almost all commercial CMC controllers now include an option for a network card allowing for full access to communications networks. Single paradigm for models, PLC, and motion expression—The committee believes that this is readily achievable with DOS partition. Mandatory extensibility and portability—The committee believes that success depends on these capabilities, which are not readily available today but will be commercially available in 2 to 3 years. Hard real-time capability—The committee agrees that hard real-time control is a required capability of any CMC controller. Such capability is most readily available from established commercial CNC controller manufacturers. The TIME program maintains that currently available COTS controllers fall short in meeting the needs and desires of the munitions industry, as shown in Table 5–1. The TIME program anticipates that the OMAC, when fully developed, will allow for a unique open solution that meets all of the munitions industry needs and desires. OMAC technology is being developed to allow all control vendors to modify the basic behavior of the controller to fit their methodology, as outlined in Table 5–2. TIME anticipates that the OMAC control architecture, when fully developed, will provide a unique solution to the controls requirements of the TIME program. It will be possible to design OMAC controls with the entire lifecycle needs of the controls engineer in mind and without the legacy constraints that hinder a majority of today’s COTS control products. Engineers and designers of control systems will be provided with a single development environment that supports a “train-of-thought” development effort. The engineer will not have to worry about whether the algorithm necessary for the control activity needs data from a PLC or motion system. The engineer will concentrate on the problem and the OMAC environment will assure access to all data necessary to solve the problem. In short, the OMAC environment will allow the control engineer to concentrate on control problems and not the problems of the development environment.
OCR for page 88
Munitions Manufacturing: A Call for Modernization TABLE 5–1 TIME Needs and Desires Versus Current COTS Controller Capabilities, as Expressed by the TIME Program (McWilliams, 2000b) Munitions Industry Needs and Desires COTS Controller Shortfalls Support for model-based control Model-based controls are constrained by the limitations of the development language. Structured text has only rudimentary math capabilities, thereby limiting the complexity of the model and requiring that the model run on the controller. Closed loops throughout the controller PLC and motion TIME’s definition of closing loops is not constrained to a single control discipline. No commercial controllers allow for closing loops to levels that include changing control laws and interacting with the entire control architecture. High-speed interfacility deterministic communications DCOM is heavily utilized as communications infrastructure and does not meet real-time deterministic requirements because of latency and timeout constraints. Single development paradigm for PLC, models, and motion logic The market is led by simple motion and modeling extensions to PLC products. No product provides the combination of complex modeling and motion along with PLC activities. Most vendors require separate products for each area. Extensibility and portability Attempts at a portability standard from PLCopen3 will fall short as long as it accepts partial compliance. Extensibility is limited with the single control product (PLC, motion) and does not allow for product growth between these areas. Hard real-time capability Most major microcomputer-based control products do not currently support hard real time across PLC, motion, and modeling. 3 Further information is available online at <http://www.plcopen.org>.
OCR for page 89
Munitions Manufacturing: A Call for Modernization TABLE 5–2 OMAC’s Planned Features That Meet Munitions Industry Needs and Desires Munitions Industry Needs and Desires Planned OMAC Features Support for model-based control Introduction of model algorithms is allowed throughout the controller, independent of whether it involves axis position, input/output, or calculated variables. Closed loops throughout the controller, PLC, and motion Access to all variables within the control system is allowed, independent of type. Data are not classified as being PLC, motion, or model data. Control algorithms have open access to all data within the control system. High-speed interfacility deterministic communications High speed T1 communications between remote sites will be utilized. Single development paradigm for PLC, model, and motion logic The OMAC development environment provides a single location for the expression of all logic, independent of whether it is PLC, or model motion. The class definitions for all layers of the control system are immediately available to the controls developer without switching tools. Extensibility and portability The JAVA expression of the OMAC controller provides an industry standard mechanism for the control logic of all aspects of the control to move from location to location. The single development environment allows for the extensibility of all aspects of the control system without respect to it being a PLC, motion, or modeling problem. The development concentrates on the control problem and does not have an arbitrary partitioning. Hard real-time capability The OMAC is built on top of VenturCom’s RTX environment. The RTX environment is recognized by Microsoft and the controls industry as the leading hard real-time extension to Microsoft’s Windows NT environment.
OCR for page 90
Munitions Manufacturing: A Call for Modernization COMMITTEE ASSESSMENT OF CONTROLLERS Needs Versus Wants in the Munitions Industry The DoD has a strong history of helping U.S. industry by supplying a relatively small amount of seed money to facilitate the development of new manufacturing technologies needed for both weapons production and the commercial sector. Some of these efforts have paid good dividends for both types of users. The efforts that have worked well were in areas where industry could not see the commercial need or could not afford the development investment. Numerical control, Automatically Programmed Tool (APT) programming language, and carbon fiber composites technology are good examples of successful technologies that were given a critically important boost by having their development appended to important defense missions. The OMAC situation is different. The U.S. CMC industry clearly foresees the CMC becoming nothing more than software inside a standard microcomputer. Furthermore, it is committed to developing such a CMC and has included it in its plans. But today the CMC market is demanding something else. CNCs using microcomputer components and standard commercial software have become so low in cost that they appear to be riding the curve of microcomputer prices. Customers, including big auto companies and small job shops, are buying the largest number of machine tools as commodities (small lathes, small electrical discharge machining units, punch presses, and vertical machining centers), with many suppliers having adequate capacity and quality, and the purchase finally depending only on price. The CMC manufacturer cannot increase prices because of competition. This means that the servo loop cannot be put completely into an existing operating system designed for word processing until it is economical to do so. This is of little interest to the real users of machine tools. But it presents a real hardship to development engineers. When they want to develop a modified servo loop, they must work in unfamiliar code, which takes them much longer than if they could use their familiar programming languages and operating systems. This has been the constant lament of software developers since the first computers were built. However, the presence of unfamiliar code has not stopped private industry from creating the developments that manufacturers really want and are willing to pay for. For example, many installed flexible manufacturing systems communicate with machines from different manufacturers, talk upstream to MRP systems, manage tooling requirements from the toolroom, report equipment performance to the maintenance department, and optimize their own workloads. These things were difficult for the developers to create but not unusually difficult. There are many examples of the best U.S. manufacturers using COTS CMC technology and adapting it to their various business strategies. It is never exactly the way they want it at first, but in spite of the lack of the OMAC, they have become best-in-class manufacturers.
OCR for page 91
Munitions Manufacturing: A Call for Modernization Today, a leading job shop in Minnesota uses a COTS flexible machining cell to make aluminum parts. This is not unusual. But this shop will deliver the parts in just a few days from receipt of order, even if they have to write a new part program and even if the part requires many different machining operations all over its surface. Their competitors take weeks to do the same thing. The Minnesota shop can do this because they have taken the best of standard machining capability and the best computer-aided programming software and learned how to use them together. They can manufacture any aluminum part that fits on their machines at an economic order quantity of one, with no time lost for setup changeover. Their machines are producing a wide variety of parts, 24 hours per day, 7 days per week, with over 90 percent uptime. It was difficult for the manufacturing engineers to develop this capability, but their management focused on the right problems and the engineers solved them. Now they are unique in their capability. They are the most flexible and responsive supplier in their market niche, and they did it without the convenience of the OMAC for their manufacturing engineers. Conclusion: TIME should be taking full advantage of COTS systems and technologies that can directly address critical Army production problems, rather than investing in new technology development where COTS solutions exist. The munitions industry can make dramatic improvements in their shop floor operations by buying, installing, and integrating the excellent machine tool controllers now available from commercial suppliers (e.g., GE/Fanuc, Mazak, and Mass). In recent years these controllers have been expanded in their capability, file handling operations, sensor integrations, and integration with higher-level CAD/CAM systems. They are used on a day-to-day basis by advanced machine shops all over the United States and in other countries. Advanced open architecture controllers are available from several companies such as Delta Tau and MSDI, but these are not needed for the TIME mission. Even more experimental platforms—such as the OMAC—are available from research laboratories, but in the opinion of the committee, these are well beyond the current scope and needs of TIME. Commercial off-the Shelf Controls Versus Industry Needs Until the mid-1980s, all of the CMC machines supplied by machine tool vendors had closed architecture controllers provided by companies such as Fanuc, Mazak, and Cincinnati Milacron (now Acramatic Siemens). This meant that a user or programmer was constrained to work with the predefined library of G and M codes (now the RS-274 standard) that were supplied with each vendor-specific controller. This resulted in limited library functions that were written in local formats. They were not open to third-party software developers who might have supplied routines in the C programming language for new CAD information or to the new machining sensors coming onto the market. This was sometimes a
OCR for page 92
Munitions Manufacturing: A Call for Modernization problem for companies with highly complex or rapidly changing machining needs. The limited library functions written in local formats do not generally cause problems for standard day-to-day machining operations. Likewise, they are highly unlikely to cause problems in controlling the relatively straightforward processes and machining operations typically found in munitions factories. Most of these processes and machining operations have been performed for decades in Army munitions plants without the benefits of controllers of any type. Machines with recent open architecture controllers (e.g., Greenfeld et al. 1989) allow faster access between high-level computer-aided design (CAD), computer-aided process planning, and computer-aided manufacturing (CAM). For example, (1) highly complex casting geometries in CAD can be readily converted into cutting tool motions for mold making; (2) nonuniform rational B-spline curved surfaces can be downloaded from CAD and executed on a standard three-axis milling machine (Hillaire et al. 1998); and (3) today’s open architecture COTS controllers allow a machine tool to automatically compensate for errors in positioning of the work piece and make possible the active control of the machining process by accepting input from external sensors. This results in faster production, more flexibility, and more opportunity for on-machine inspection and quality control. These are highly sophisticated examples of tasks that can be readily accomplished when today’s COTS CAD/CAM packages are linked to well-documented COTS Fanuc, Mazak, or Cincinnati Milacron CMC controllers. These interconnected systems can be seen all over the world carrying out first-class machining. U.S. automobile companies use such environments for daily production, and the machine shops in Silicon Valley that supply the large semiconductor equipment manufacturers use standard CAD/CAM packages linked to standard Fanuc, Mazak, or Cincinnati Milacron CMC controllers. In the last few years, the controller industry has brought to market new controllers that satisfy many of the goals of OMAC and many of the needs of the munitions industry. Commercial vendors are moving on their own to fill the needs of the marketplace. In the committee’s opinion, what is available now is likely to do everything needed by the Army for the foreseeable future, even if there are some extraordinary requirements for the munitions industry. The TIME program cited, as an example, the need for an OMAC so that twin-screw extruders can be operated by remote control (for safety reasons) to make identical batches of the approximately 120 energetics formulations in the munitions inventory today, with virtually no operator training regarding the specifics of each formulation. The committee believes that this task can be successfully performed using a combination of today’s COTS controllers and today’s COTS Internet communications technologies. This opinion was reinforced by Tom Gassenbeck,4 president of E-Manufacturing, a Canadian company. This company has, for several years, been interfacing controllers, such as those sold by Fanuc, to networks. The COTS technologies being sold by E-manufacturing demonstrate that OMAC technologies are not required for interconnection of equipment in the munitions industry. 4 Personal communication with Richard Kegg, TIME Committee Member, August 24, 2000.
OCR for page 93
Munitions Manufacturing: A Call for Modernization The NRC committee is critical of TIME’s heavy financial investment in the ongoing OMAC development activities. The OMAC work to date may be of good quality and may ultimately benefit both users with highly sophisticated requirements and users with less sophisticated requirements, as typically found in the munitions industry. The committee agrees with the TIME program that if and when the OMAC development effort is successfully completed and when a wide variety of proven components are commercially available, the effort to modernize the munitions industry would benefit in terms of (1) lower-cost hardware and software due to increased head-to-head competition, (2) easier system integration and easier integration of enhanced functions, (3) opportunities for third parties and end-users to incorporate custom application controls and strategies, and (4) faster product realization cycles. However, it appears to the committee that very substantial additional investments will be required before these benefits can begin to be realized, and it is not at all clear to the committee when, if ever, the OMAC will be commercially adopted. Although techniques for the transfer of technologies from laboratories and their implementation into commercially useful products have improved somewhat in the last decade, technology transfer remains an art as much as a science. Many barriers are typically encountered when technologies are transferred from one organization to another, and it is anticipated that the OMAC will be no exception. According to Rob Kling, a professor of information science and information systems at Indiana University, there is a “big gap between the conception and the execution” of any new computer or software system (Manufacturing News 1999). Thus, commercialization and implementation are likely to be major issues. One way to reduce these problems is to involve the commercializer in the development project. This means, at a minimum, that it must have a voice in planning and must be able to closely follow the development work. The best way for this to happen is for the commercializer to license the rights and commit substantial financial and human resources to the effort at an early stage in the development process. Although there are many participants in the OMAC development effort, LLNL remains by far the dominant one. TIME has yet to find a commercializer for the OMAC that is willing to invest substantial time and resources. OMACs may someday be a major improvement over the COTS microcomputer-based CNCs that are offered today by the machine tool controller industry. However, based on the experience of the controller industry, the OMAC will not be simple and inexpensive to complete. This raises the concern that the OMAC may be many years from having a validated architecture and a multitude of thoroughly validated COTS OMAC products from which the munitions industry could select and use with confidence, knowing that manuals, technical service, and continuing product improvement will be available as needed. For example, the committee is concerned that safety issues in an open environment must be thoroughly addressed and validated before components are implemented into the already dangerous munitions manufacturing industry. The common API must include a complete firewall between the user’s custom applications and the control builder’s real-time operating systems. Reuse of common hardware and software components to construct a controller can lead to
OCR for page 94
Munitions Manufacturing: A Call for Modernization unexpected results if safety considerations are not factored into each component’s design, accounted for in the integrated solution, and thoroughly validated for all conceivable operating conditions. System safety, traditionally the responsibility of the machine tool builder must, with the advent of OMAC, become a major skill and responsibility of the system integrator. Today’s munitions factories are vastly behind the state of the market, having little or no CMC-controlled equipment and virtually no computers. There is a pressing need to install today’s COTS CMC controllers with their very adequate links to CAD/CAM systems, as described in other parts of this document. The Army, through TIME, should also be investing in basic microcomputer platforms and Internet connections to begin to bring some of the munitions facilities up-to-date. OMAC can be compared with a Grand Prix race car. It is highly desirable to have, but the needs of the munitions industry are far less demanding, much like day-to-day commuting for which a standard (COTS) sedan is sufficient. It is possible that the control capabilities required for processing advanced energetics and for manufacturing advanced semicustom smart munitions might be greatly enabled by the successful completion of the OMAC. However, no such needs or requirements were presented to this committee and, until the requirements for these products are further defined, such requirements remain speculative in nature. One advantage of OMAC is that its implementation can be a gradual process. Control components can be implemented gradually as they become available or as needed to achieve the level of openness required by the application. Thus, unless there is a compelling need that cannot be addressed by COTS controllers, there is little need for massive government funding of OMAC to further its development. Rather, the munitions industry can be upgraded according to a prioritization of needs using COTS technologies. OMAC technologies can be inserted as needed when the technologies have matured through commercial development and validation, such that there is a high degree of confidence in their reliability and suitability. The committee believes that OMAC, in the near term, has the potential to provide more benefits to companies that already have state-of-the-art COTS controllers and CAD/CAM systems linked to their supply chains, than to the munitions industry, which has yet to implement these basic capabilities. The Army should not be investing in advanced controller technologies when funds for basic upgrades to the munitions industry, which should have higher priority, are virtually nonexistent. The committee also had difficulty reconciling the extensive focus of TIME resources on the development of real-time OMAC controls when the DoD munitions replenishment scenario anticipates a process requiring up to a year to get replenishment lines up and running. It appears to the committee that, in an era of limited defense budgets, progress in implementing today’s COTS technologies will do far more to assure rapid scale-up for replenishment than trying to develop OMAC technologies that may ultimately offer only marginal advantages. Similarly, the committee believes that the melt pour process line at the Iowa Army Ammunition Plant can be remotely operated successfully and safely using COTS technologies and that only slight improvements are likely in the near
OCR for page 95
Munitions Manufacturing: A Call for Modernization future with OMAC technologies. For instance, processes of similar complexity in the paper industry are successfully controlled using today’s COTS technologies. It should be pointed out that according to the TIME program (Frampton and McWilliams 2000), this state-of-the-art process line presently has no modern process controls. It is run directly by operators with the aid of thermometers and the experience and judgment of the operators concerning properties such as the appearance of the “applesauce-like” texture of the mixture of molten trinitrotoluene (TNT). It was reported to the committee that the process is highly dangerous to the operators and frequently yields defective product, which, if allowed to leave the facility, would pose significant hazards to the (warfighter) users. It was reported to the committee (Frampton and McWilliams 2000) that the Army has efforts under way to document this manual process as a first step toward implementing up-to-date control technologies. The committee believes that perhaps someday this process may be more elegantly controlled using the OMAC, but it is not needed. Process control experts at corporations such as Honeywell International and Foxboro5 design and install control systems for processes of equivalent or greater complexity on a routine basis. Recommendation: The committee recommends that the Army issue contracts to commercial process control experts to implement modern, commercial-off-the-shelf control technologies on energetics process equipment in government-owned munitions manufacturing facilities. The committee encountered considerable controversy regarding OMAC. Enthusiastic arguments were given for termination of OMAC, as well as for increasing its support. Opinions ranged from “badly needed by the Army and by industry,” to “totally unnecessary.” Some perceive the OMAC project making substantial progress. Others view it as a government-funded project that has been under way for almost a decade and has not provided any payback. Some believe that OMAC will someday offer substantial benefits. Others believe that it will result in little value to routine users of CNCs. Some say that OMAC will offer substantial advantages over today’s COTS controllers, while others say that commercial industry’s latest offerings will do almost everything that OMAC will someday do at a fraction of the cost of bringing OMAC to commercialization. Some believe that OMAC offers such high commercial value in the marketplace that large companies will adopt it. Conversely, others feel that the development effort will cease if government funding is stopped. It is outside of the mission of this committee to settle the overall debate regarding the ultimate value of OMAC for commercial and defense production and whether the government should continue to subsidize OMAC development. However, the committee has studied the matter sufficiently to form some conclusions and recommendations regarding the importance of the OMAC to the munitions industry today. First, there appear to be serious questions regarding the amount of investment that is justified in rehabilitating and upgrading the existing, 5 These corporate examples in no way constitute a recommendation by the NRC.
OCR for page 96
Munitions Manufacturing: A Call for Modernization deteriorating munitions manufacturing base. The committee was shown no evidence of recent, detailed studies of specific munitions manufacturing equipment needs and process needs in response to up-to-date warfighting scenarios and emerging energetics and smart munitions technologies. Such studies are important for assessing risks and setting investment priorities and should include a bottom-up assessment of controller requirements for the munitions industry over the next 10 years. Specifically identified needs should be compared, application by application, with the capabilities of COTS controllers. Although it may well have made sense that initial OMAC development work focus on the development of an overall framework for open architecture, the committee strongly questions the investment of TIME program funds in OMAC development prior to a determination of clearly identified munitions industry needs (as opposed to desires) for such technologies. Such studies should be completed before any final decision can be made regarding the appropriateness of further Army investment in OMAC. The committee has not been made aware of any munitions manufacturing need (as opposed to wishes) that cannot be adequately addressed by today’s COTS controllers. Recommendation: As part of overall munitions industry planning, the TIME program should conduct a bottom-up munitions industry study of specific machine and process controller requirements for the next 10 years. Recommendation: TIME should divest itself of further OMAC development and proceed immediately to transfer the OMAC, as is, to commercial sponsors.
Representative terms from entire chapter: