In Part 1 of this series, we defined digital models, digital twins, and the process of change management, impact assessment, and requirements management. We also described the challenges that static PDF documents pose to modern engineering workflow, i.e. they don’t play nice with the digital thread and cost companies far too much time, money, and risk. Now, let’s talk about what engineering documents look like when converted to digital models and dig into some of the benefits. To be clear, when we use the term engineering documents, we refer to a wide range of document types including internal company specifications, external industry standards, assembly instructions, procurement technical data packages (TDPs), test methods, and supplier requirements, and other similar types.

“What do you hire an engineering document to do?”

There are many answers of course, but in general, an engineer or technical professional uses an engineering document to:

1. answer a very specific question, or
2. to identify the requirements or procedures to implement the task at hand.

In a future state, perhaps a human will simply ask the document a question and get an answer (are you listening ChatGPT?). Or perhaps machines will read the documents and construct step-by-step instructions for humans. Or better still, perhaps one day machines will read the documents and act on their own to complete the required tasks. All of these scenarios are possible with digital models and machine-readable documents. But since AI hasn’t come far enough yet, and since documents don’t talk back to users or machines, and since most documents are not in the form of digital models, users must interrogate the document by reading it. I know, I know – some of you are thinking, with a smirk and an eye-roll, “You poooooor guy, having to actually read something!!”

We are not trying to eliminate reading or trying to remove humans from the engineering process. Reading an engineering document can be compared to reading a story, except that this story is about requirements, tables, graphs, equations, test methods, parts, materials, processes, relationships to other documents, dependencies, and more. Reading a long, technically complex story just to find one small piece of data, or only to be sent onward to another referenced document is a time-consuming and tedious process. If machines could do it reliably and accurately, wouldn’t we prefer that? Furthermore, one of the most wasteful aspects of the current use patterns of engineering documents is that readers all over the world duplicate the same tasks over and over. Right now, there are likely a dozen people reading standard A123 and seeking an answer to the same exact question. In many cases, the question has already been answered many times by other people undertaking the same task, possibly even by someone in the same organization. There is no option to reuse the information gleaned by others and no option to automatically extract just the information you need without reading a large section of the document. If you take this micro-example and multiply it by the legions of engineers and technicians doing this work around the world, you can see how inefficient it is to use documents in PDF format.

LEGO: the ultimate reusable building block.

A Solution: Documents as Digital Models

Recall our definition of a digital model: “a virtual representation of a real or imagined object that describes the structure, context, and behavior of that object.” Similarly, we can define the structure, context, and behavior of a document (and its individual data elements), and use that intelligence in many useful ways.

Structure. Although a document does not have a physical structure per se, it has sections containing labeled subject matter, table of contents that define the overall content, and tables and figures each of which illustrates a topic, references, and requirements. We can develop standardized ways of presenting and labeling these structures so they can be understood and acted upon by machines and software.

Context. Using AI and semantic models, we can make useful inferences about the purpose of the document. We can infer what parts, materials, and processes are addressed, the qualitative and quantitative values given, and even where in the product development lifecycle the document and its data are most useful.

Behavior. Based on the data in the document, we can describe how this document and its individual data elements relate to every other document and data element in the product development lifecycle, what references and dependencies exist, what test methods are required, and more. If the document were able to speak to you, it might tell you that it’s a member of the MIL Spec screw thread family, that it is only applicable for non-ferrous metals, that it has 14 other dependent references, that it is relevant to three of your products on the market and two under development, and that it is invalid for use after December 31, 2021. A human being might take hours to determine all that information on their own (not including nap time).

A digital model document has defined structure, context, and behaviors.

SWISS Digital Models Tell a Story

When we combine the structure, context, and behavior of a document, a story emerges which can be used to inform, improve, and automate the product development lifecycle. We can develop actionable intelligence and deliver answers to users on-demand, or even proactively based on the task at hand.

For example, if a machine operator is drilling a hole and finishing the surface, the precise instructions can be delivered to them based on the material, the purpose of the hole, and the finish spec ordered by the customer. These instructions may be contained in multiple documents related to drilling, finishing, threading, and testing, but when converted to digital models, the required data elements (whose individual meaning and context is understood by the system) can be gathered together automatically and delivered as one coherent set of instructions. From unstructured data comes structure and intelligence.

As another example, a contract manufacturer may receive a large set of specifications and instructions from a customer. The normal process is for a team of estimators to review the entire set of documents and determine the requirements, the process steps, the parts and materials needed, and the cost (among other priorities). Several companies have stated that this process can take up to 30 hours per document and is prone to human error. An AI-enhanced system that is analyzing the customer’s specs as digital models can quickly determine the parts and materials necessary, any overly-expensive requirements, long lead-time items (like castings and forgings), equipment and time needed to deliver the product, obsolete references, hazardous materials, opportunities for additive manufacturing, and more. The result is a better, faster, and more accurate quote with less of the team’s time.

Change Management Made Easy with Digital Models

Let’s go back to the aircraft example from Part 1. Standards and requirements are changing frequently and when those changes are communicated within PDF files, it creates tedious manual labor to “follow the breadcrumbs” and assess the impact of those changes on products and processes. However, if the authoritative changes are distributed in a machine-readable format (like a SWISS digital model), then an AI-enhanced system that uses semantic reasoning (like the SWISS platform) can automatically highlight changes from the previous versions, determine how the changes impact product development, specify the parts, materials, and processes affected, and prescribe the steps needed to implement the changes.

A well-trained system could even raise red flags for potential pitfalls such as hard-to-find parts or materials, long lead-time components, hazardous materials, regulatory requirements, price spikes in specified parts, and much more. Engineers, designers, maintenance technicians and anyone else working on the aircraft can be notified instantly of changes that impact their specific area, and they can see those changes reflected automatically in the digital twin. The use of AI, semantic reasoning, and machine-readable digital models can shave dozens or hundreds of hours off a project and significantly reduce human errors.

Capabilities, Wow

When documents shift from flat-text artifacts to digital model data, a whole new world of capabilities emerges. For example:

• AI Linking – Rather than click reference links from document to document and ending up at the top of each document, an AI-enhanced system can analyze the context around the links and direct the user to the exact piece of data in the referenced link. Rather than wading through pages and pages of data to find what you need, AI can take you where you need to go.
• Reference Network – Since the system sees all the relationships between documents and data, the system can list for you all the related references, and even draw a map of the network of relationships.
• Requirements Extraction – AI and semantic ontologies can be used to automatically identify and extract all the requirements in a document or a web of documents, and classify them according to subject, importance, parts/materials/process, etc.
• API Queries – Digital model data can be queried using simple API calls from other applications. For example, a PLM (product lifecycle management) system could query for any obsolete references related to a set of documents. The results could display instantly in the PLM interface.
• Reusable Digital Data – Rather than copying/pasting content from one place to another (a very common and tedious task), users could “drag and drop” linked digital data elements into applications like MS Word, PowerPoint, and others, while maintaining the authoritative fidelity and maintaining the link to their authoritative sources. When changes occur at the source, they can be communicated to anyone using that piece of data, anywhere in the enterprise. In SWISS, we call this process “transclusion” and we’ll talk about it much more in a future post.
• Machine Readability – As described in many examples here, digital models can be machine readable which means that machines (software) can read, interpret, and even take actions based on the information. Again, let’s not remove humans from the loop, but let’s enable machines to do what humans cannot, which frees up more time for humans to do what machines cannot.

SWISS AI and semantic reasoning can decompose unstructured data into structured machine-readable text.

• CAD Model Intelligence – Engineering drawings often contain references to standards and other engineering documents. An AI-enhanced system with knowledge of those references could provide valuable inferences about the drawings such as the related parts, materials, processes, the opportunities for additive manufacturing, and more.

• HAL 9000 or Jarvis, You Choose – Ultimately, we may reach “engineering nirvana” where humans direct AI to provide the intelligence we need to make better decisions faster and then to execute decisions at our command. IronMan relied on Jarvis for all sorts of data and intelligence and he trusted Jarvis with his life. Whether you trust AI or not, it’s hard to argue with the vision of using technology to reduce duplicative non-value-added work, shorten cycle times, and mitigate risk. (BTW, you don’t have to remind me that HAL 9000 was not trustworthy 😉

A Final Analogy (for You and Your Grandma)

I once explained SWISS digital models to my 80-year old mom as being like 3-D glasses. When you go to a 3-D movie, those funky glasses enable you to see a world that you wouldn’t see otherwise. If you take the glasses off, the exact same information is there on screen, but your brain doesn’t have the tools to process it. When you overlay SWISS on top of complex engineering documents, it provides intelligence and capabilities that you wouldn’t get otherwise. It changes the entire experience. And since that experience hasn’t changed much since the mid-90s, we think it’s time. Will you join us?

The Secret Meatloaf

Hopefully, you read all of Part 2 and didn’t just skip right to the secret meatloaf. My son does that during movies and it kills me! As promised in Part 1, the secret parts, materials, and processes of my meatloaf are:

• Caramelize the onions with butter and garlic, then add to the ground beef.
• Add 1 Tbsp Gochujang sauce for a flavorful kick. If you’re averse to the kick, substitute ketchup.
• Cook about a dozen cherry tomatoes in olive oil, garlic, and salt until the tomatoes start to pop, the garlic is soft, and the smell is incredible. Puree this mixture and add to the ground beef (or add without pureeing).
• Halfway through cooking, mix 1 tbsp of your favorite BBQ sauce with 1 tbsp of mayonnaise. Yes, seriously mayonnaise. Glaze the top of the meatloaf with the mixture (learn why mayo is nearly the perfect marinade and glazing ingredient).
• Cook until the top is browned and crispy.
• Mmmmm!

What is a Digital Model?

What is a Digital Twin?

Physical Twins Can Update Their Digital Twins

Here’s the Rub (and the Pain)

Throughout a product development lifecycle and over the course of a product’s lifetime in-the-field, the producer or owner must manage a long list of varied and changing requirements distributed across multiple authoritative sources from inside and outside the enterprise. Knowing what those changes are and knowing how they impact their product or operation is a dual task called change management and impact assessment. A related process of identifying requirements for implementation is often called requirements management.

For example, when Eastern Airlines orders a plane with the upgraded landing gear, or when a new standard is published that affects a product under development, the changes can affect dozens or hundreds of parts, materials, or processes, and require significant design and engineering modifications downstream. Since the mid 1990s, these changes have been published most commonly as PDF documents. It may be a single standalone document or an entirely new specification summarized in a TDP (Technical Data Package). One technician can spend hours or days wading through PDF documents, identifying the changes, assessing their impact on relevant areas of the business, and communicating the modifications to appropriate teams, usually by copying/pasting the new requirements into new documents like work instructions, assembly instructions, internal corporate specifications, and more. The time, knowledge, and seemingly bottomless patience required for this task is monumental. As a result, the process of change management, impact assessment, and requirements management are often saddled with long delays, duplicative work, and human errors.

In an ideal world, we would automate these tasks and teach software and machines to do the work. Imagine a machine that could analyze engineering documents and industry standards and not only highlight changes from the previous versions, but provide intelligent instructions on how the changes impact product development, and prescribe the steps needed to accomplish the changes. A trained machine could even raise alarms for potential troubles down the road such as hard-to-find parts or materials, long lead-time components, hazardous materials, regulatory requirements, price spikes in specified parts, and much more.

Unfortunately, PDF documents are not machine readable so the automation scenario is not widespread and requires significant software training. To a machine, the text, tables, graphs, images, and equations contained in PDF documents are merely characters laid out in random order, without context and meaning. Furthermore, nearly every author of an engineering document lays their characters out in different ways. Industry standards in particular are highly unstandardized, but this problem also exists among OEMs and suppliers across any one particular industry. (The aerospace industry has challenged its members to develop a standardized model of digitally compatible information, outlined in a paper by AIA’s Future of Aerospace Standardization Working Group (FASWG).)

We can teach machines to read PDF – something that is already underway in the SWISS platform – but a much more efficient solution is to transform documents from flat “dead-text” artifacts into intelligent digital models that describe the structure, context, and behavior of the information contained therein.

So What Now?

By now, I hope you are salivating at the potential benefits of transforming engineering documents into a format compatible with digital models and the Digital Thread. But if you’re not, don’t worry, we’ve laid it all out in Part 2 of this article.

Part 2 will show you how the concepts of digital models can be applied to engineering documents, industry standards, product engineering, change management, and requirements management, resulting in lower costs, faster cycle times, and reduced risk.

And of course, you’ll learn the secret ingredients in my meatloaf 😉

The United States Department of Defense manages one of the largest procurement budgets in the world. Of the department’s $700 Billion annual budget, more than $200 billion is spent on goods and services from contractors.1 Purchases run the gamut from aircraft carriers to combat boots.

There are enormous challenges in procuring this array of goods and services with the right level of quality and speed while stewarding taxpayer dollars. One branch of the Department of Defense, the Defense Logistics Agency (DLA), is turning to digital models from XSB to reduce the cost, time, and errors associated with PDF-based procurement.

Defense Logistics Agency

The Defense Logistics Agency, the nation’s combat logistics support agency, manages the end-to-end global defense supply chain for the five military services. DLA procures more than $46 billion annually across several supply chains: subsistence (food/water), clothing and textiles, bulk petroleum and other energy products, construction material and equipment, personal demand items, medical material and equipment, and repair parts for land, sea and air systems.

DLA’s Clothing and Textile department manages more than $1.3 billion in demand for nearly 5000 Clothing and Individual Equipment items. Consider, for example, the Army Combat Uniform (ACU). The ACU is a complex garment incorporating camouflage, chemical treatments, fire retardant, NIR Signature management technology, and permanent IR IFF squares for identification with night goggles–just to name a few features designed to keep our soldiers safe and healthy.

The Problem

The requirements to procure, manufacture and test the ACU are distributed across a web of related, but disconnected, technical documents including Specifications and Standards, Purchase Descriptions (PD), and other Technical Data Packages (TDP) with multiple Interim Changes. Product technical requirements are derived from documents authored inside (e.g., Military specs) and outside the Government (e.g., Non-Government Standards from ASTM, AATCC, and NFPA, etc.). These technical documents vary in age from thirty-year-old scanned PDFs, to more modern Microsoft Word and XML Documents. The purchase description for the ACU has references to 98 documents and 5053 pages from 13 document sources.

ACU Network of Requirements Documents
Different stakeholders including the military services, DLA Product and Contract Specialists, Government and industry testing labs, and suppliers to the government must find and use the requirements embedded in these documents. The documents are rich with technical information but were made for printing and reading. They are poor containers for technical data. They are not interoperable, and their uneven format makes it difficult for users to search, query, use, reuse, update, edit and manage. The problem is further complicated as different stakeholder groups establish multiple, independent collections of these documents on network drives, Microsoft SharePoint instances, on their local desktops, and even paper in folders.

Requirements in traditional documents are stored as static and disconnected objects, but they represent a dynamic web of concepts distributed across an ever-changing network managed by different authorities. The disconnected nature of a document-based approach makes tech data management difficult and can result in decisions based on inconsistent, incomplete, and out-of-date information. Different Clothing & Textile division stakeholders use the same information to perform different tasks during the product life cycle. A Product Specialist may support a military service by inserting contract-specific Interim Changes into an item requirement. In response, the manufacturer needs to alter a factory work instruction to ensure the finished product includes these changes. An industry test lab must change a First Article Test Plan to reflect the revised requirement. The DLA Product Test Center needs to know the impact of that change is reflected in manufacturer test reports. The problem with this disconnected document approach is that changes to one document are poorly communicated to other document stakeholders.

The Solution: TexSpecs

The DLA turned to XSB to help them create TexSpecs: “interoperable structured digital models of purchase descriptions, interim changes, and other specification-based technical documents which reduces the cost, time, and errors associated with PDF-based tech data management.”2

DLA’s transformation to a Model-Based Enterprise results in improved decision making and increased confidence that a design will perform as expected. This Model-Based approach enables users to query, edit, and analyze technical data that was previously locked in the document format. Linking the concepts within and between documents provides powerful change management and configuration control mechanisms. According to Deloitte, this approach can generate up to 65% process cost savings. It also helps DLA’s Clothing & Textile stakeholders avoid mistakes and rework resulting from decisions made with out-of-date information.

A Closer Look

XSB helped DLA convert documents from 13 different sources to interoperable, linked data models using Artificial Intelligence and semantic technology. The collection of these former documents, now models, is stored as a knowledge base, or graph, and is called the Digital Model Library (DML). The knowledge graph establishes a single, enduring, authoritative source of truth that captures the state, history, and relationships between tech data sources. Changes made to a document model in the DML propagate throughout all affected data and systems, ensuring stakeholders have accurate and up-to-date information. This Model-Based digital thread is the product DNA for the management of the associated clothing and individual equipment items. Digital models of Clothing & Textile documents provide many advantages over PDF documents:

consistent and instantaneous integration of Interim Changes
enhanced configuration management across stakeholders,
Automated and rapid analysis to ensure compliance with government procurement procedures and interoperability with other digital models from Government and Industry.
In addition, digital models can be exported as MS Word documents enabling the Agency to retain its traditional, document-based processes and workflows while undergoing digital transformation.

The knowledge graph, or DML, can be accessed by humans through a Web browser, or by machines and systems through a powerful Application Programming Interface (API). The DML now contains 146 Purchase Descriptions, 620 Government Specifications, Standards, and Commercial Item Descriptions, and 2130 Non-Government Standards from ASTM, AATCC, and others.

1 The Department of Defense (DOD) An Orientation November 12, 2021

2 DLA C&T Modernization Efforts with DLA MUST Program TexSpecs& SRP Tool Brief for Joint Advanced Planning Brief to Industry (JAPBI)

A team from XSB including CEO, Rupert Hopkins, board member Bob Solomon, and Andrew Bank won the award for best paper in the 2022 World Standards Day paper competition. Their paper, entitled “The Next Generation of Engineering Standards: A Proposal for Digital Transformation”, addresses the shortcomings of legacy PDF engineering documents and industry standards and proposes a technical solution to benefit all parties involved including standards developers, enterprise software providers, standards end-users, manufacturers, and others involved in the engineering supply chain.

Their solution, called digital twin documents, builds on the familiar concept of the model-based enterprise. Digital twins were born during the 1990s as 2D part drawings were transformed into 3D CAD models, resulting in dramatic productivity improvements in design and manufacturing.

A digital twin document is a standardized data-centric representation of a flat-text document in which each of the data elements — such as text, tables, graphs, equations, images, requirements, and more — are transformed into individual, interoperable, and reusable data points, connected in a network of references and related concepts. These data points are aware of their position in the network, their status (active, inactive, superseded, etc.), and their relationship to other data points, and can therefore communicate to end users about changes and the impact of those changes on other parts, materials, or processes. SWISS digital twin documents are structured sets of data that are machine readable and even machine interpretable. The authors believe that in the near future, engineering documents and industry standards will be read and interpreted as much by machines as by humans.

Digital twin documents can enable a new world of capabilities and value-added benefits that are impossible to achieve with PDF files and like their CAD counterparts, they will jumpstart another massive wave of productivity gains.

You can read the full paper in the Standardization Journal at the link below. Please share it with your colleagues and let us know your thoughts.

Read the full paper here.

The World Standards Day Paper Competition is sponsored by SES – The Society for Standards Professionals.