4
By ROSS DOWNING, Principal Engineer, The Boeing Company Delivering product standards data in multiple forms, to multiple platforms, from a single source of data. 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 differ- ent when I go to work. Some folks are using CAD systems to cre- ate 3D renditions of parts and assemblies. ese tools tell you if parts interfere with each other and can analyze structural integri- ty. Other folks are using Product Data Man- agement (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 sys- tems to let buyers know when to order more parts. We have become used to the automa- tion 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 op- eration 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 Product Standard in a Product’s Lifecycle Product Standards Material specs Standard parts Process specs Design manuals etc… mfg control, inspection reqs, facilities control, supersession, options selection criteria/guidelines qualified sources, matls control, receiving inspection, supersession subset of all info for other processes PSDD PSDS PSDS Support Product Maintenance Spares Mod’s Investigation Build Product Tool setup Fabricate Assemble Inspect Manage Mfg Resources Procure Manage inventory Distribute Product Standards callouts Design Product Select standards Apply standards Callouts to material specs, process specs & std parts Product Standards Data Management Supplier issues Obsolescence Hazardous materials Quality and reliability etc… selection preference to read and manually interpret the document and transfer any data that I need by hand. e question is, why should anybody care if the standards data is not digital and auto- mated like the other design and manufactur- ing data? e answer is simple. In the aerospace world, standards often comprise roughly half of the product defini- tion 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 leav- ing you to manually calculate the rest and mail in the other half of the return. Manually transferring the PDF standards data to digi- tal systems, manually maintaining the data concurrently, and maintaining configuration control is expensive, time consuming, and er- ror 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 sys- tems? Again, the answer is simple. e product specific data in these product lifecycle management (PLM) systems and the product standards data have completely different lifecycles. e different lifecycle of the standards is what gives them much of their value. Putting standards data into de- sign 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

By Ross Downing, Principal Engineer, The Boeing Company ...partsolutions.com.br/wp...Boeing-Article-AMD-June-July-2011.pdf · The Boeing Company Delivering product ... no manual intervention

Embed Size (px)

Citation preview

By Ross Downing, Principal Engineer, The Boeing Company

Delivering product standards data in multiple forms, to multiple platforms, from a single source of data.

RequiringDigital 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 differ-ent when I go to work.

Some folks are using CAD systems to cre-ate 3D renditions of parts and assemblies. These tools tell you if parts interfere with each other and can analyze structural integri-ty. Other folks are using Product Data Man-agement (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 sys-tems to let buyers know when to order more parts. We have become used to the automa-tion 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 op-eration 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

Product Standard in a Product’s LifecycleProduct Standards� Material specs� Standard parts� Process specs� Design manuals� etc…

mfg control, inspectionreqs, facilities control,supersession, options

selectioncriteria/guidelines

qualif ied sources, matlscontrol, receiving

inspection, supersession

subset of all infofor other processes

PSDD PSDSPSDS

Support Product� Maintenance� Spares� Mod’s� InvestigationBuild Product

� Tool setup� Fabricate� Assemble� Inspect

Manage Mfg Resources� Procure� Manage inventory� Distribute

Product Standardscallouts

Design Product� Select standards� Apply standards

Callouts to material specs, process specs & std parts

Product StandardsData Management� Supplier issues� Obsolescence� Hazardous materials� Quality and reliability� etc…

selectionpreference

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 auto-mated like the other design and manufactur-ing data? The answer is simple.

In the aerospace world, standards often comprise roughly half of the product defini-tion 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 leav-ing you to manually calculate the rest and mail in the other half of the return. Manually transferring the PDF standards data to digi-tal systems, manually maintaining the data concurrently, and maintaining configuration control is expensive, time consuming, and er-

ror 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 sys-tems? 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 de-sign 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

For personal use only

actual authority and about what to use when they are out of sync. Having independent standards allow improvements, and the addi-tion 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 configura-tion managed separately, but it needs to be digitally interoperable with the product spe-cific data.

HeaDing TowaRD DigiTalEarly 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 – Wiz-ards– that use a digital interpretation of the logic of process specifications to automati-cally navigate and interpret them. These are great because the production folks do not need to read through and interpret the speci-

fications 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 Inte-grated Product Standards Management Gate-way (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 se-lected, 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 con-figuration management system for Boeing authored product standards and related data. When a new or revised standard is published,

it produces a PDF document and automati-cally 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 sTRaTegyFive years ago, it became clear that the pieces that we had been creating needed to be in-tegrated 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 informa-tion 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 archi-tecture to facilitate data interoperability).

Manage and deliver product standards from single authoritative source and auto-

Product Standards as Digital Data (PSDD)

Manage Product Standards Within a Program

Product Definition Standards Tools

Customers (Design Engineering, Program M&P)

Deliver Enterprise Product Standards

Produce & Support Standards Tools

Customers (Supplier Management, Manufacturing, Customer Support)

Design Engineer applies standards data…….to drawing / PDM / dataset

Interpret and deliver standards data…….via Wizard, manually, etc.

Manufacturing Engineer applies standards data…….to production systems

Prod

uct D

efin

ition

Too

lsProduce and Support Tools

PSDD Content ManagementSingle Source of Data

Product Standards Corpus Families of

Standards

Standards Related Data (Attributes not in the standard, Connect points, Manufacturing aid data, Export control status, etc.)

Publish

Standards Like Data (Vendor Parts, SCDs, Models, etc.)

Program Centric Data (Program ASLs, Program Substitution Documents, etc.)

Data Centric Authoring (Wizardization, Rulesets, etc.)

Infrastructure (MIM, Workflow, etc.)

PSDD Product Standards User Interface

SOA Interface

SOA Interface

For personal use only

matically feed data to all delivery systems on publishing.

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

Author standards as digital files using a schema that allows digital definition of stan-dards data (numbers, formulas, conditions, logic, etc.) and allows publishing of the standards data in all necessary formats (PDF documents, CAD models, digital files, logi-cal 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, savingsThe digital standards related systems that we had developed had not yet been implement-ed 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 imple-ment 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 prod-uct support costs related to standards went

one sTanDaRDWith Boeing’s aggressive initiative to have one Master Source of standards data available across the enter-prise, PARTsolutions is being utilized to author, publish, and deploy those collected standards in a multi-CAD/PDM environment. Tradi-tional methods of managing standards in PDM systems have proven difficult, if not impossible to manage. The days of Just-In-Case popula-tion of standards in the PDM system is unwieldy, with the ability to find and re-use those parts when required near impossible. Tradition-ally, 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 stan-dards system, creating parts on the fly, and subsequently managed in the PDM system is a new paradigm that is getting traction, as compa-nies look for new ways to reduce time to market goals by eliminating non value added design tasks.

— Tim Thomas PARTsolutions, LLC

Product Standards as Digital Data

Repositoryof Content

Components

Databases

Internet and Intranet

Multimedia

Transformationat publish

CAD

Product Standards vs. ProductLifecycle

PSDD – Functional Architecture (with overlay of current & soon-to-be applications)

Define & Control Authoring Publishing DeliveryView Product Standard Documents

Select Product Standards for a Product Definition

Apply Product Standardsto Product Definition

Get Relevant Manufacturing Data from Product Standards

Change Request Management

implemented as PSDD & Legacy mix

implemented as PSDD Only

implemented as Legacy Only

Change Review / Coordination

Data-Centric Capable

Document -Centric Only

Transform

Shape-Centric

Data-Centric

Document-Centric

Release

Convert / Load from Legacy Repository

Data Access Infrastructure

Get Relevant Customer Support data

ProductLifecycle

ProductStandardLifecycle

For personal use only

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 interpreta-tion errors and increased product quality. We increased data interoperability with using sys-tems and increased data quality. The benefits extend across the supply chain.

woRking TogeTHeRNow 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 expen-sive 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 stan-dards data at the same level as PLM system data. Boeing only authors a portion of the standards that we use. We are working to con-vince 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 provid-ers that there are opportunities for them in digital standards applications.

The reality is, we are not the only ones do-ing this, and our methods are not the only so-lutions. 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 individu-als, 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 de-

velop 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 im-mediate effect on the bottom line.

Who knows, maybe someday our stan-dards systems will be as smart as our cars and phones.

The Boeing Companyseattle, wawww.boeing.com

PaRTsolutions, llC200 Techne Center Dr ste 118Milford, oH 45150(513) 453-0453www.partsolutions.com

Reprinted with permission by Aerospace Manufacturing and Design, September 2011

designdesign

For personal use only