Requiring Digital Interoperability

A few months ago, my sister bought a new car. She was excited to show me everything that it could do. It ‘knows’ where it is at all times, and will give up to the minute local weather at the touch of a button. It can find the closest gas station and tell her when to turn left to get there. It tells her when to change the oil or when a tire pressure is low. It will even call for help if she has an accident or someone steals the car. We have become used to these automated services in our cars, our phones, and in most every other aspect of our lives. It is no different when I go to work.

Some folks are using CAD systems to create 3D renditions of parts and assemblies. These tools tell you if parts interfere with each other and can analyze structural integrity. Other folks are using Product Data Management (PDM) tools that pull data from the CAD systems to create a bill of materials, feed data to planning systems to lay out the sequence of operations that a mechanic needs to follow, and feed data to procurement systems to let buyers know when to order more parts. We have become used to the automation and digital interoperability in the design and manufacturing world. I keep running into one big exception, though.

When the design calls for a product standard – like a standard part or a material defined by a material specification, or an operation defined by a process specification – I have to leave the digital world and pull out a paper document or view a PDF document. All of the automation goes away and I have to read and manually interpret the document and transfer any data that I need by hand.

The question is, why should anybody care if the standards data is not digital and automated like the other design and manufacturing data? The answer is simple.

In the aerospace world, standards often comprise roughly half of the product definition data. Having half-digital data and half paper data creates problems. It is like having tax software that does half of the calculations for you and e-files half of your return leaving you to manually calculate the rest and mail in the other half of the return. Manually transferring the PDF standards data to digital systems, manually maintaining the data concurrently, and maintaining configuration control is expensive, time consuming, and error prone. We need the data in a digital form that is interoperable with other systems.

Some folks ask, why do you not just re-key the standards data into your CAD, PDM, manufacturing, and procurement systems? Again, the answer is simple.

The product specific data in these product lifecycle management (PLM) systems and the product standards data have completely different lifecycles. The different lifecycle of the standards is what gives them much of their value. Putting standards data into design systems would require design revisions every time there is a revision to a standard. Putting standards data in both the standards release system and the design systems will also create configuration management problems. Questions come up about which one is the actual authority and about what to use when they are out of sync. Having independent standards allow improvements, and the addition of options without having to revise the product design. This facilitates design reuse and enables cost reduction. The standards data needs to be maintained and configuration managed separately, but it needs to be digitally interoperable with the product specific data.

Heading Toward Digital
Early on, many of us at Boeing recognized the disparity between the standards data and the product specific data as we watched the product specific data become increasingly digital. While the PLM systems have grown up over the past couple of decades, we have had several projects where we began moving standards data in the digital direction and to digitally deliver the data. There have been some notable ones.

We developed product standards – Wizards– that use a digital interpretation of the logic of process specifications to automatically navigate and interpret them. These are great because the production folks do not need to read through and interpret the specifications themselves. The Wizard asks a few questions about the operation and the specific area of work. It delivers a short, specific work instruction, with only the values and parts of the specification that they need to do the job.

We developed an application called Integrated Product Standards Management Gateway (iPSMG) that delivers standard part notes and CAD models, material notes, and process notes directly to the CAD and PDM systems. A design engineer can select individual parts and notes or run a knowledge base that uses design rules and constraints and standards data to automatically select properly matched parts, materials, and process notes. Once selected, iPSMG uses a utility to automatically create CAD models for the standard parts and then it places the part models and the part, material, and process notes into the CAD and PDM systems, properly formatted and in the correct places.

We developed an overarching system of systems that we call Product Standards as Digital Data (PSDD). It provides a digital authoring, content management, and configuration management system for Boeing authored product standards and related data. When a new or revised standard is published, it produces a PDF document and automatically feeds digital data from the standard to using systems (like Wizards and iPSMG). PSDD gives us a digital single source for our standards that interoperates with our other systems that need standards data.

A Single Strategy
Five years ago, it became clear that the pieces that we had been creating needed to be integrated into a single strategy. We produced the Boeing Product Standards Long Range Strategic Plan. Key to the strategy is the goal that standards users will not need to access a PDF document for a standard. Instead, the optimum amount of specification information will be delivered in a role-based format to the point of use when needed with little or no manual intervention. The strategy has also driven some other goals:

Raise product standards technology to the level of product design technology (CAD, PDM, etc.) and ensure that the data is interoperable with other product definition data and systems (use service oriented architecture to facilitate data interoperability).

Manage and deliver product standards from single authoritative source and automatically feed data to all delivery systems on publishing.

Never re-key data. Author standards data once and draw data from the single authoritative source (different standards may come from different single sources).

Author standards as digital files using a schema that allows digital definition of standards data (numbers, formulas, conditions, logic, etc.) and allows publishing of the standards data in all necessary formats (PDF documents, CAD models, digital files, logical and conditional interpretations for smart systems, etc.).

Encourage and support the development of a government and industry wide common data model and hierarchical ontology for product standards.

Costs, Savings
The digital standards related systems that we had developed had not yet been implemented for all standards or for all downstream PLM systems at Boeing but all of them have been implemented for some of our standards and systems. So, what did we get for all of the work and investment where we did implement them? On the negative side, the cost and complexity of authoring standards has gone up. That was expected. On the positive side, the recurring manufacturing and product support costs related to standards went down. The savings are orders of magnitude greater than the increased authoring costs. We reduced the time needed to navigate and interpret standards. We eliminated data re-keying. We reduced rework due to interpretation errors and increased product quality. We increased data interoperability with using systems and increased data quality. The benefits extend across the supply chain.
 

Working Together
Now that we have done all of this, we want to convince the rest of the world to follow a similar path. We realize that in order to get the full benefit, we need to be able to get digital data from more than just our own standards. We use government and industry standards and we need that data in digital form, as well. For us to create derivative works to digitize standards from other sources would be expensive and could raise ownership issues. The best scenario would be to have all of the standards owners provide data in digital form using a common ontology. In this world, we would pull standards data from suppliers, partners, and other standards developing organizations (SDO). We would integrate it with our data and use it in our PLM systems. On the other end, we would provide digital standards data and services to our customers, suppliers, and partners. The data would move seamlessly.

We cannot do this alone. Boeing is part of a connected web of industry. We are working to convince other manufacturers that they can cut costs and improve quality by having standards data at the same level as PLM system data. Boeing only authors a portion of the standards that we use. We are working to convince other SDOs that there are new business opportunities in providing digital standards data as well as PDFs. As sharp as our IT folks are, Boeing is not a software company. We are working to convince software solution providers that there are opportunities for them in digital standards applications.

The reality is, we are not the only ones doing this, and our methods are not the only solutions. There are others working to solve the same problems, but the issue is that most of us are doing it in our own worlds and may be moving in different directions. We do not want to tell everyone what the solution is, we just want to participate in defining it. If we move as an industry rather than as individuals, we will reduce our individual costs while increasing our benefits. Our collective data interoperability costs alone are estimated to be in the billions of dollars per year. If we can develop standardized data models for standards and if we can develop standards systems and applications that share data seamlessly, we will all benefit. Any improvement will have an immediate effect on the bottom line.

Who knows, maybe someday our standards systems will be as smart as our cars and phones.


The Boeing Co.
Seattle, WA
boeing.com

PARTsolutions, LLC
Rolling Hills Estates, CA
partsolutions.com

ONE STANDARD

With Boeing’s aggressive initiative to have one Master Source of standards data available across the enterprise, PARTsolutions is being utilized to author, publish, and deploy those collected standards in a multi-CAD/PDM environment. Traditional methods of managing standards in PDM systems have proven difficult, if not impossible to manage. The days of Just-In-Case population of standards in the PDM system is unwieldy, with the ability to find and re-use those parts when required near impossible. Traditionally, teams of designers are modeling parts in the CAD system of choice, which should be created and managed by the SDO’s in a CAD agnostic platform. This includes supplier parts, or commodity type parts, often referred as standards. National Electric Motor Association (NEMA) motors and National Fluid Power Association (NFPA) cylinders come to mind. The ability to have a Just-in-Time standards system, creating parts on the fly, and subsequently managed in the PDM system is a new paradigm that is getting traction, as companies look for new ways to reduce time to market goals by eliminating non value added design tasks.

— Tim Thomas
PARTsolutions, LLC