Navigating the Production Maze: The Topic Mapped Enterprise

Thomas M. Insalaco
James David Mason


A manufacturing enterprise is an intricate web of links among products, their components, their materials, and the facilities needed to turn materials into components and completed products. Facilities, full of equipment, also depend on trained staff for operation. The Y-12 National Security Complex, owned by the U.S. Department of Energy, has a rather specialized product line, but its problems are typical of large-scale manufacturing in many high-tech industries. Faced with the need to maintain products that may have been built decades ago, Y-12 needs to develop a system that can rapidly find out what tools are needed to make parts for a particular product or, if tools are replaced, which products will be affected. Our proposed solution is a topic map that treats our products in detail, the component flows, and the facilities and tools available in the Complex. We hope to extend this map to include other aspects of our operations, including the skills and staffing levels necessary to operate our processes. Although the Topic Map is still in preliminary development, we are already learning new things about our enterprise from it.

Keywords: Topic Maps

Thomas M. Insalaco

Thomas M. Insalaco is a program planner and analyst in the Planning & Integration department at BWXT Y-12. His work focuses on medium- to long-range planning, life-cycle planning, cost estimating, and program integration. He uses tools like simulation and topic maps to help him discover and understand relationships between program requirements, program plans, resource availabilities and dependencies, project risks, and costs. His assignments at Y-12 have included leading the development of the Y-12 Ten-year Baseline Plan; leading the weapons program cost estimating team; leading the technical team for the Weapons Record Archival Project; being the technical manager for the CALS Roadmap demonstrations and presentations in 1994 and 1995; leading the deployment for Y-12’s shop floor control system; and managing the Y-12 Concurrent Engineering Center. Mr. Insalaco is certified as a Production and Inventory Control Manager (CPIM) by the American Production and Inventory Control Society (APICS) (1992), and he has a M.S. in industrial engineering from Ohio State University (1990) and a B.A. in mathematics and computer science from the State University College of New York at Potsdam (1979).

James David Mason

James D. Mason, originally trained as a mediaevalist and linguist, has been a writer, systems developer, and manufacturing engineer at U.S. Department of Energy facilities in Oak Ridge since the late 1970s. In 1981, he joined the ISO’s work on standards for document management and interchange. He has chaired ISO/IEC JTC1/SC34, which is responsible for SGML, DSSSL, topic maps, and related standards, since 1985. Dr. Mason has been a frequent writer and speaker on standards and their applications. For his work on SGML, Dr. Mason has received the Gutenberg Award from Printing Industries of America and the Tekkie Award from GCA. Dr. Mason was Chairman of the Knowledge Technologies 2002 conference sponsored by IDEAlliance. He is currently working on information systems to support the classification community at DOE's Y-12 National Security Complex (Y-12) in Oak Ridge, Tennessee.

Navigating the Production Maze: The Topic Mapped Enterprise

Thomas M. Insalaco [Y-12 National Security Complex]
James David Mason [Y-12 National Security Complex]

Extreme Markup Languages 2004® (Montréal, Québec)

Copyright © 2004 Thomas M. Insalaco and James David Mason. Reproduced with permission.

The Problem: Understanding Complexity

Since its establishment over 60 years ago under the Manhattan Project, The Y-12 National Security Complex (Y-12, formerly known as the Oak Ridge Y-12 Plant) has been devoted to their manufacture of highly specialized weapons components. Although it is a large facility, Y-12 is not so large as, for example, an automobile assembly plant, nor does it produce such a large volume of products. Nonetheless, it is a microcosm of complex manufacturing. Y-12 has foundries, forges, a rolling mill, and numerous chemical-production lines. The output of the basic production facilities is processed by many machine shops, inspected by sophisticated instruments, and finally assembled into finished products that must be certified before delivery to the Department of Defense, our primary customer. The analysis that we are developing for Y-12, while specific to our plant and products, could be extended by analogy to any manufacturing problem.

Even though new products are not being designed, Y-12 is responsible for maintenance of numerous product lines that remain in the U.S. stockpile. The original fabrication of some of these products took place several decades ago, but they may be returned to us for refurbishment or replacement of components, such as plastics, that may gradually deteriorate. For this reason, we need to keep track of how products were made years ago, what tools were used, and what tools are currently available. When the customer selects a product line for refurbishment, we must reconstitute the production chain for making it. While an automobile manufacturer rarely returns to production of past models (though Ford did make some new Model Ts for its hundredth birthday), it does retool frequently for new lines and models. The process for reconfiguring a factory is similar in either case.

Y-12 has some additional functions in addition to assembly/refurbishment of weapons systems. Some old systems are being retired, and the size of the stockpile for some enduring systems is being reduced. As a result, products are being dismantled, and materials are being recovered and recycled. Y-12 is also the storage site for some materials, such as enriched uranium, which cannot be released to general circulation and may be monitored by the International Atomic Energy Agency of the UN. The "unmanufacturing" process is not precisely a mirror image of the original construction, so a single model of a hierarchical parts breakdown is not suitable. Furthermore, the recycling of parts and materials creates lateral flows that require a more hypertext-like model than is possible with conventional databases.

At Y-12 we are undertaking a streamlining and modernization of our facility, and, as part of the planning process, we are undertaking a virtual inventory of both the products and the manufacturing capabilities, as available and as needed. Much of the information we need in this process is available, but it is in diverse forms and stored in many systems. Some of it, indeed, exists only in paper form. Even though some information exists in current databases, the relationships we need to examine do not lend themselves to conventional systems. Much of what we want to know crosses systems. Although we may know a lot about individual machine tools, we cannot always correlate this with the full range of products. So we cannot tell what product lines would be affected if a tool is surplussed or replaced.

We have decided that the best way of integrating and examining the diverse data is a topic map. Because a topic map is not restricted to fixed dimensions, we can link data in ways that are not possible in conventional tabular databases. We have built a proof-of-principle system that brings together two major views of Y-12: product lines and production facilities. For each of these approaches, we have established multiple dimensions. Products have been dissected into components, and these can be examined not only according to original product but also according to material and production process. In the prototype system we have concentrated on numerically controlled machine tools, for which the notable dimensions include type, location, and manufacturer. These two views of the plant intersect, and we are able, for some selected products, to walk down from the product through components to the individual machines used to make the components, and back up to other components that also pass through these machines. As we expand the system over the next few months, we expect to have our first comprehensive view of the complete manufacturing complex.

From Factory to Ontology

Our design process began late last year with a data collection phase. We discovered that many groups around the plant had their own separate hoards of information, most of which had been collected for very localized purposes. For the product lines we could find data sheets that listed the component parts, their part numbers and names, their materials and sizes. We discovered that one group had compiled a very detailed database of all the numerically controlled machine tools in the plant. Building managers could generally come up with lists of all the tools in the shops that were their responsibility. Another group had listed all the machines used to produce a certain group of parts. From the plant laboratory we obtained a list of all the materials for which tests existed.

With these collections in hand, we had two tasks: to develop a design for our topic map and to convert the data for input to the map. The basic ontology of the topic map is conditioned by both the information available and the linkages we realized we needed. Data conversion has largely been by extraction from Excel (our engineers tend to put everything into Excel—including, occasionally, memos) and Access. We extract HTML from Excel (not the most pleasant HTML, by any means!) and use XSLT scripts to build XTM components that are merged into the overall topic map.

Products and Components

For about half a dozen systems in the enduring stockpile, we have complete "data sheets," which include product drawings and tables that list the components along with their identifiers, materials, weights, and classifications as well as some supplementary data. We have similar data for another group of systems that, while not being maintained anymore, are being disassembled to meet treaty requirements. All this data has been compiled into tables that are simple in structure, if detailed in terms of the information they contain. Each system is broken down into its subassemblies and parts. Every part has a part number, a name, a material, a shape, a size, etc. The first translations we wrote created topics for the systems and parts, with separate topics for names, part numbers, and numerous other characteristics. The transformations then added associations between parts and their parent systems, their part numbers, and the like.

Developing the topic map quickly became more complex, however. When systems are brought back for refurbishment, parts may be renumbered and renamed. In some cases, there are slight changes in dimensions, so that the replacement part really isn't quite the same as the original. We also rename parts for convenience in separating old and new versions. Accordingly, it is necessary to build additional associations between old and new names and numbers.

Over the years, we have used many subvarieties of certain materials, such as stainless steel. Furthermore, there have been many names given to some materials, some as codewords to allow open discussion of sensitive materials, others just as insiders' jargon. We need to transcribe the data-sheet information for historical reasons. However, if we take data only from the data sheets, we will miss the fact that two programs may use the same material but have called it by different names. So it has been necessary for a subject-matter expert (SME) to read through the tables and build in additional information so that associations will bring together all the parts made from, for example, enriched uranium, no matter what it was being called at any given time.

Other information in the tables must also be analyzed by an SME to create useful associations in the topic map. Data sheets do not actually specify what basic process is used to create a part (e.g., casting, forging). The SME must look at the drawing in the data sheet and interpret the size and shape of each part, then assign it a generic process, which will become the subject of an association in the topic map. Data sheets typically give the actual weights of parts. This is important information, but it is not directly useful for planning purposes. We have several casting lines in our foundries, distinguished not only by what materials they process but also by the sizes of castings they can make. What matters for analyzing plant capacity is which casting lines will be required for a product. In building the topic map, it is not useful to create topics for each weight, such as 3.4 kg. The SME instead assigns each cast part to a general weight class according to the process line to be used. The generic assignment becomes the basis for a primary association in the the topic map, and the actual weight becomes an appropriately scoped occurrence of the part.

Each part is thus represented by a set of topics, which represent its identity, and a series of associations that link it to its parent system and to certain generic information, such as the material of which it is made and the process by which it is initially formed. It carries with it, as internal occurrences, much of the specific data that is known but which does not affect planning for its manufacturing. The topic map of systems and parts can be viewed as a stand-alone online system for its own value. The ontology of systems and parts eventually becomes the basis for a sequence of pages in the topic-map browser (Fig. 1).

Figure 1
[Link to open this graphic in a separate page]

System and part ontology

Production Facilities

Analyzing production facilities is quite different from analyzing products. All of our major products that appear in the topic map are completed systems, and there are only about two dozen of those to be considered. We have many production areas and thousands of production devices. Production areas range from open machine shops to environmentally controlled assembly areas. We have only one 7,500-ton press but hundreds of lathes. Some areas do chemical processing, while others do X-rays. Most of the information we have about equipment is related to scheduling maintenance, not analyzing workflow. The only quick associations we can make are by general area: is this the rubber shop, the graphite shop, the uranium rolling mill, or one of the shops for machining exotic materials?

The best information we have about production equipment is a database about numerically controlled (NC) machine tools. For each tool we typically know the maker and model, the serial number, our internal inventory number, and details about its controller. We have similar data on the controllers themselves. Although the database is not yet fully populated, we also have the potential for capturing the capabilities of individual tools: what is the swing over the bed of this lathe, how many degrees of freedom are possible for that multi-axis mill? From this collection, which we have made a model for our tool ontology, we originally built a stand-alone topic map, separate from the one concerned with products, parts, and materials. The map of NC tools allowed us to track such things as the pairings between tools and controllers or the locations of all the instances of a particular model. The overall pattern of information about tools and their locations gives rise to another set of navigational pages (Fig. 2).

Figure 2
[Link to open this graphic in a separate page]

High-level machine-tool and controller ontology

We are still in the data-collection phase for other production equipment. Although we have very good data on NC tools, it is only partially relevant to coordinate-measuring machines and hardly at all to heat-treatment furnaces. About the only common elements applicable across many types of equipment are such things as location and inventory number, so we are planing to extend our ontology.

Assembling the Map

Our initial studies had given us two topic maps: one of products, the other of tools. For production analysis, we needed to merge these separate maps. Once again we fell back on the SMEs. A recent study of one of the systems that is about to be refurbished had produced some workflows for major components. However, the SME preparing this study had done it as a walkthrough of a shop floor: Part X begins at the second lathe on the first row, then moves to the third mill on the first row. So we called in the SME who had done the database on NC tools, and he provided us a small mapping between the tools in his collection and their locations on the floor. With this new set of associations, we can build a bridge between the product map and the tools map.

The result was a single merged topic map. For certain products, at least, we can walk down from the product through particular parts families to all the tools needed to produce each part, right down to the serial numbers of individual tools. From a tool, we can walk back up to see what parts, from which systems, pass through it. The topic map is now on the verge of becoming a useful planning tool. If we populate it with similar data for other product systems, we shall be able to use it to see such things as the impact of replacing a tool because of requirements for the current program of work on the next program scheduled to come into the plant.

Although we have had initial success with this topic map, we are now rethinking the relationships between system parts and their processing. The current map depends too much on the expertise of an individual SME and his knowledge of how parts flowed through specific shops at a specific time in the past. As we reconfigure the plant, such information will become less relevant. In the past, we often dedicated a particular machine to a specific process on a specific part. When that process on a part was complete, the part moved to yet another dedicated machine. Assignment of processes to machines was often on the basis of the knowledge and skill of the operators (high-precision manufacturing is still as much art as science). We are now planning to move to a new generation of "agile tools" that might combine the functions of, say, a lathe and a five-axis mill, in a single device. The introduction of such tools will completely change many old routings.

The new design, which is just beginning to take shape, will depend on generic workflows rather than specific historical part routings. There are certain generic processes that are followed for all systems. Machining a small, hollow, uranium casting follows the same pattern no matter what system we are producing. Molding powdered material in an isostatic press is similarly a generic process.

We have collected a series of such generic workflows and are beginning to create topics to represent them. The topics will represent generic steps, such as "turn inside contour," "unmold pressed part," or "X-ray casting for voids." Workflow routings will be built from these components through previous/subsequent associations. Tools and facilities will then be assigned through scoped associations: for example, the outside contour of a small uranium part is measured by a different device from the outside contour of a large steel one because they are produced in different shops (Fig. 3).

Figure 3
[Link to open this graphic in a separate page]

Generic process environment

Almost every product has some unusual feature that cannot be covered by the generic workflows. The next system to be refurbished has caused us to acquire a special NC tool to cut a unique hole in one of the castings. Such special processes mean that we shall continue to reflect them in the topic map by one-of-a-kind associations. These associations will be closer to the ones we have in the preliminary map than to those mediated through the generic workflows.

The associations between parts and tools in the current map will be scoped as "historical" because they are worth retaining, and displaying, under certain conditions. New associations to the new generic workflows will be created, based on the current associations among parts, their sizes, materials, and generic processes. For future planning, these workflows will assume increasing importance. With the generic workflows, we shall be able to create new, scoped associations between processes and facilities and tools that can change as the plant is modernized.

Interfaces to the Map

The interface to the system is through custom HTML pages suited to our data. The page for a part, accordingly, can look quite different from the page for a material or a machine tool. Pages can change their appearance according to the information available. If a part has received a new name and number for a refurbishment program, we can also display the corresponding name and number for the original program, together with a link to the page for the counterpart component (and vice versa). Because this is a topic map, we can connect pages in multiple directions.

Current entry points into the system are from either the systems side (primary entry) or the NC tools side (secondary entry). Entering from the systems side leads to weapons systems, which leads to parts by system, or to a list of all the named parts across all systems, or to a list of materials. Entry into the tools side brings either a list of shops and then inventory lists for the shops, a list of all the tools and controllers in the system, sorted according to manufacturers and models, or to a list sorted according to inventory numbers and other identifiers.

A typical part page (Fig. 4) contains sections for part identity, materials, and a possible routing through shops and tools. (Because our real products and parts cannot generally be discussed in public, we have constructed substitute data from bicycle manufacturers' parts breakdowns, creating part numbers and the like where necessary. Although the routings of the parts through shops are fictitious, the machines are based on real examples.) Thus the frame for a real bicycle ( is made from aluminum alloy. The page for this part is linked back to the page for the whole bicycle system from which it is taken (that page would contain a complete parts breakdown for the system). In the constructed example, its current part number is cross-referenced to that of a similar earlier model; the hyperlink on the number would shift the browser's focus to that earlier part. The drawings for both the current and previous parts are linked in as external occurrences. A link for the material, aluminum, would bring up a (hyperlinked) list of other parts made of the same material. The production routing, showing links to the shops and the tools in them, is a major key to our expected use of the topic map as a planning tool. This particular page does not show some of the optional items, such as details of the manufacturing process.

Figure 4
[Link to open this graphic in a separate page]

Page for a typical part

Following the link to one of the tools leads to a page with considerable information about the device's capabilities (Fig. 5). The links to other tools by the same manufacturer and to other instances for the same tool are particularly useful with older tools, for which it is sometimes necessary to scavenge parts no longer on the market. Historical data (not all of which is shown on the sample page) is useful in planning which tools need to be upgraded or replaced.

Figure 5
[Link to open this graphic in a separate page]

Capabilities page for a numerically controlled tool

We want very much to create different views into the topic map. Not all potential users have the same need to know, so we may want a view that allows a user, for example, just to look at the status of tools in a particular shop but not see the components that flow through the shop. We are considering linking this topic map to our online system to support classification analysts; these users may want to see only the details of the products and probably will not be concerned with production flows. The use of scoped associations should allow us to take historical or planning snapshots of systems and production.

Navigating the Enterprise

Applying topic maps to an enterprise offers an opportunity to rethink the enterprise. The information in the topic map may not be new, but everything-linked-every-way model behind the map offers new ways of seeing existing information. Almost all the data in the Y-12 topic map has come from existing sources. The process of analysis that includes harmonizing data and designing the ontology before the map can be assembled gave us new understanding of our material—and frequently sent us out to collect additional data. Even though the eventual results are implicit in the selection of data, design of the ontology, and construction of the user interface, the total effect of the project can be felt only through using the resulting system in operation.

The Y-12 system in its current state involves the merging of over a dozen individual topic maps. These maps document the breakdown of systems into parts, the identifiers applied to individual parts, the links between parts and materials, parts and processes, and parts and tools. The current collection of NC tools is represented by a single map. Although the topic map collection has been extracted from small number of tables, it is much more easily understood than the tables. In particular, the topic map system allows selective focus, even when a large amount of information is being presented. A thirty-one–column table (the source for the tools map) throws too much data at the user to be digested at a glance! The topic map can present this information with a focus on capabilities of a single shop, or on similar tools in multiple shops. It can focus on tools or controllers, on manufacturers or models. A database management system could provide such multiple views, but only within a closed system. What the database does not provide is the easy ability to shift among many kinds of data that have been collected, arranged, and stored in diverse ways.

Only the data on NC tools was stored in a database. The most important information, about the products themselves, was in an assortment of hand-made spreadsheets of various designs. None of these offered much flexibility for display. The topic map system thus became a unifying technology for spreadsheets, databases, and other sources. The addition of a single bridging map between the products and tools opened up capabilities that were nowhere available in the separate systems from which the product began. With the addition of that simple map, it became possible to start with a system and walk the path down through parts to processes and eventually to individual NC tools, with specific serial numbers, on the shop floor. Similarly, it is possible to start with a tool and walk up through the parts it processes to see which production programs will be affected by a change in its status. Besides these journeys, which traverse the entire map, as it were, there are many shorter paths that restrict themselves to smaller regions. But even these localized paths are enhanced by the map. For the first time, for example, we can see how many product systems include a given part or require a particular material. Previously, finding such information would have required switching among different systems—or even searching for paper documents in different repositories.

The system we have presented is very much a work-in-progress. We have entered data about the systems in the enduring stockpile and systems that are being dismantled. The generic workflows have been developed but have not been exported to the topic map. Except for NC tools, equipment inventories are still somewhat inconsistent, as well as incomplete. We are still working on the links between the workflows and the equipment that supports them. We must depend on other groups to define access-control requirements to be incorporated into the map.

Even though the system is incomplete, we already have several achievements. Analysis of equipment is helping us plan which machine controllers need continuing software support. Our experience with the pilot projects that have led to this system plan have given us confidence in its success. We expect to show a complete working prototype by the end of this fiscal year. Our goal is to bring the entire system up on a centralized Web server so that it can serve the appropriate communities in Y-12 and DOE. We look forward to putting the system in the hands of a larger community so we can see what they discover by using it.


The Y-12 National Security Complex is managed for the U.S. Department of Energy by BWXT Y-12, L.L.C., under contract DE-AC05-00OR22800.

This document was prepared as an account of work sponsored by an agency of the U.S. Government. Neither the United States Government nor any agency thereof, nor Contractor, nor any of their employees, makes any warranty, express or implied, or assumes any legal liability or responsibility for the accuracy, completeness, use made, or usefulness of any information, apparatus, product, or process disclosed, or represents that its use would not infringe privately owned rights. Reference herein to any specific commercial product, process, or service by trade name, trademark, manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation, or favoring by the United States Government or any agency or Contractor thereof. The views and opinions of authors expressed herein do not necessarily state or reflect those of the United States Government or any agency or Contractor thereof. Further, BWXT Y-12 is not responsible for the contents of any off-site pages referenced.

This document was prepared by a contractor of the U.S. Government under contract DE-AC05-00OR22800. Accordingly, the U.S. Government retains a nonexclusive, royalty-free license to publish or reproduce these documents, or to allow others to do so, for U.S. Government purposes. These documents may be freely distributed and used for non-commercial, scientific and educational purposes.

Navigating the Production Maze: The Topic Mapped Enterprise

Thomas M. Insalaco [Y-12 National Security Complex]
James David Mason [Y-12 National Security Complex]