Improving supply chain collaboration

The model based enterprise offers great promise for collaboration in the extended supply chain. The vision of taking a 3D solid image of a product, flowing that image to virtually any source, and feeding it into a machine that almost magically spits out perfect hardware is an intriguing concept. The visionaries who promote this potential see complex systems coming together in a fraction of the time, with dramatically reduced cost. They see seamless collaboration around these digital product images that extends to every level of the supply chain. While the vision is admirable, it is still just that.

Recent experience with major programs – both military and commercial – that were touted as all model-driven, have had some notable successes, but have often fallen short of the vision. This is not because of fundamental flaws in the models or the engineers who created them, but rather a failure to fully recognize the inherent limitations of over-dependence on the model – without giving necessary consideration to everything that ultimately goes into the definition and production of hardware that meets design intent.

Understanding the Details
It is the oldest of clichés, but the devil really is in the details. The model may indeed encapsulate the entire dimensional and geometric definition of a product, but it is failing to heed those things about the product that are not readily evident on the model that can lead to less than optimal results. It is these things that make up the complete technical data package (TDP), which are often either deeply embedded in the model or separate from the model altogether.

There is a tendency to think of the model as the end product of the design process. It is indeed the high-end part of the design effort, the part that allows the designer to apply engineering knowledge, meet a performance objective, and express some level of creativity. The rest of the effort associated with product definition – fleshing out the TDP – is the seemingly mundane part of the process. Without this mundane and often tedious step, the model will not fulfill its full potential. It is analogous to the scientist who makes a great discovery and shouts “eureka,” but fails to complete the report that really explains the discovery so that it can be applied outside of the laboratory.

Figure 1: Technical Data Package (TDP) ElementsThe TDP – much of which is separate from the model – is where many of the aspects that truly define the product reside. Moreover, the TDP is comprised of those critical details, typically referred to as characteristics, which ultimately determine whether the product will live up to the intent envisioned in the model generated by the designer. At the recent Global Product Data Interoperability Summit, Boeing noted that some 40% of the technical data necessary to create a product resides outside the model. This significant fraction typically consists of narrative guidance, including specifications, standards, and notes. Without this vital information, even the most skilled production source cannot produce hardware that meets design intent. Figure 1 illustrates the multiple inputs that make up the TDP.

To further explore this concept, consider a feature that is common to virtually every model: the hole. As a feature, a hole is comprised of multiple characteristics – diameter, depth, and taper; it may require a certain surface finish or be threaded or coated; there may be variations in tolerances for the various characteristics; it may change during production until it reaches its final nominal value; and in those instances of compound, or intersecting holes, it is necessary to determine the precise angle of intersection. These are just some of the considerations that must be addressed around this most common of features.

How many of the characteristics described above can be determined directly from a model? Depending on the level of annotation provided, the model might spell out all of the dimensions. It may or may not offer tolerances. It is not likely that surface finishes or coatings can be derived from the model, because these are generally included in notes or specifications. For compound holes, datums from which to determine angles are needed. Features not only represent many individual characteristics, but for a production source it is necessary to repeatedly decode the feature within the model. This process of laboriously picking out each characteristic is manually intensive, error prone, and a breeding ground for downstream quality escapes. (See Figure 2)

Figure 2: Multiple Characteristics Within a Single FeatureAddressing the Need
The challenge is to generate a TDP that can be seamlessly, electronically integrated with the digital image of the product. Simply put, the technical data package must enable the production source – at any level of the supply chain – to access all of the information needed to generate a product that meets the full design intent. The extent of this information includes those annotations placed on the model by the designer, the ability to interrogate and obtain additional annotation data not included by the designer, and all notes, standards, and specifications that govern such things as tolerances, data references, materials, processes, and related requirements that reside outside the model. In short, there is a clear need for an intelligent technical data package.

Intelligent is an overused term that is often intended to oversell an idea or concept. In the context of the TDP it must have practical meaning and application. For a TDP, it means the ability to capture all of the characteristic-level data about a design – dimensions, geometries, notes, specifications – and identify, organize, and access them quickly and easily. Application of this intelligent TDP can then serve a wide range of operational needs, including production, quality, and downstream process control.

Figure 3: Generating the Bill of Characteristics from all Product Data SourcesAt the core of the intelligent TDP is the bill of characteristics, or BOC. Like its counterpart the bill of materials, the BOC provides complete, fully integrated, tabular documentation of every accountable characteristic for a design. The BOC’s role within the intelligent TDP is the ability to electronically link each characteristic and all of its supporting requirements with the documents that dictate how that characteristic is to be met. (See Figure 3)

Once again, if we use the hole as an example, a line item in the BOC might call out a diameter that appears on the digital model image. This diameter will simultaneously have an identifier, or balloon, that distinguishes it from the other characteristics on the model. At the same time, the BOC line item might show a reference that provides the standard for how such a hole is to be deburred, or the type and method for coating the hole. Through the BOC, all of the requirements for the characteristic are accessed and illustrated so that any gaps in the data provided on the model are filled, and information needed to meet design intent is available for the production source.

Existing Tools
Interoperability and completeness of technical data remains an issue throughout the extended supply chain. A 2007 Aerospace Industries Association survey conducted with members of the aerospace supply chain found that more than 70% of suppliers must own multiple CAD systems in order to work with the digital product data they receive from their customers. In addition, they all said that the technical data they receive is incomplete. The results of this survey underscored the need for a CAD neutral tool to enable suppliers to work with the technical data they receive, to organize it to fit their process capabilities, and to systematically identify gaps.

DISCUS software was initially developed to assist members of the aerospace and defense supply chain to identify characteristics on 2D drawings and associated documents, and create a bill of characteristics. The accumulated information was then applied in support of first article inspections, statistical process control, and related activities in compliance with the aerospace quality standard AS9100. DISCUS was successful in filling this niche, with more than 800 aerospace companies – including primes/OEMs and companies at every level of the supply chain – acquiring and applying DISCUS.

Figure 4: DISCUS enables specific references within documents to be extracted and included with their dimensional and geometric counterparts in the BOC.As DISCUS application grew, it became evident that it is more than just a first article/SPC product. It was effectively serving as the way that many companies established and organized their technical data packages. Starting with 2D drawings and now progressing to work with solid model data in a CAD neutral way, DISCUS enables the realization of the intelligent TDP. By automatically ballooning a model, DISCUS captures every annotation included on the model and immediately organizes those annotations in the BOC. The model can be augmented with supporting 2D images, such as reduced dimension drawings that contain notes, tolerances, and associated information. Finally, all narrative documents, including specifications, are captured and organized. Specific references within these documents can then be extracted and included with their dimensional and geometric counterparts in the BOC to establish the complete record of requirements for each characteristic. (See Figure 4)

The next step for DISCUS is to help the production source effectively shred the constituent elements of the bill of characteristics so that they can be used for multiple operational applications. This is another element of the intelligence enabled by DISCUS in the formulation and application of the complete technical data package. This applies downstream in production, but can be pushed upstream into the design process as well.

Downstream, the initial application of DISCUS for first articles is well proven. Users routinely achieve 50% productivity gains, with some reporting as much as 90% improvement. In addition, more recent versions of DISCUS enable the BOC information to be applied for process planning, assuring that all identified characteristics are properly documented in manufacturing planning and consumed during production. From an inspection perspective, DISCUS has the ability to link with coordinate measuring machine (CMM) applications to ensure that the characteristics identified in the TDP directly correspond with those measured by the CMM – and that the two records are fully integrated.

Upstream, DISCUS and the BOC offer significant potential enhancements to the design process – particularly in the area of producibility. Through application of DISCUS Design, process capability knowledge at the characteristic level is integrated with design practices to assist the design engineer, in conjunction with the manufacturing engineer, to achieve an affordable design – consistent with the principles of design for Six Sigma – during the early stage of the product lifecycle.

Achieving the Promise
The promise of the model based enterprise is achievable. But like similar great promises, it must be viewed as a complete entity. That entity goes beyond the model, to include all of the associated data and documentation necessary to support the model. Once this larger entity is understood, it must then be broken down into its individual pieces and the inner workings of those pieces, and, how they are mutually supportive must be understood and applied in a systematic, consistent manner.

The most fundamental piece of these inner workings – the molecular part of the promise – is at the characteristic level. The next step is organizing those characteristics, whatever their source, into a bill of characteristics. From there, using a tool like DISCUS, an intelligent technical data package that embraces the digital product image and its accompanying narrative documents can be generated. With this intelligent TDP in hand, a production source at any level of the supply chain can produce a product that is both affordable and meets all aspects of the design intent.

The model based enterprise vision is achievable today – we simply need to avoid fixating on a single element and recognize all of its facets.

DISCUS Software Co.
Columbus, OH
discussoftware.com

Partner at Renaissance Services
Springfield, OH
ren-servces.com