Specifications and standards define the parts, materials and processes used in eighty percent of all traded products in the world.1 The Department of Defense (DoD) ASSIST Database, an online repository for military specifications, standards, handbooks, and related documents (http://assist.dla.mil), lists more than 110,000 documents including specifications, standards, data item descriptions, handbooks, voluntary standards adoption notices, and other technical requirements published by the US Government. There are around 29,000 active documents in the ASSIST Library; 20,000 of these are documents from Government Preparing Activities, while 9,000 are documents from external standards developing organizations (SDOs).
The 20,000 active Government documents include references to other specifications and here’s where it gets messy: those active ASSIST documents contain more than 107,000 references to other specifications and standards. While sixty-six percent of these references are to documents from Government Preparing Activities, thirty-three percent refer to documents from more than seventy external SDOs. And we haven’t even mentioned the second-degree references yet; based on the average number of references per document, and the DoD’s requirement to follow a reference for two degrees (or “hops”), we could expect those 107,000 references to refer to documents with an additional 500,000 to one million second hop references.
These numbers only reflect references from the documents in ASSIST managed by Government Preparing Activities. ASSIST doesn’t track references from documents managed by SDOs. When Government- and SDO-developed documents, and the millions of derivative works referring to them (e.g., supplier specifications, work instructions, requests for proposals (RFPs)), get created at the enterprise level, a vast network of interrelated documents is produced that can only be navigated manually. The lack of interoperability within this network of documents poses significant challenges for users to find the content they need, stay abreast of current versions, and apply the appropriate specifications and standards to their particular application.
The Problem with PDF
Standards are typically published by Government Preparing Activities and SDOs as standalone PDF documents. Standards in PDF format were introduced around 1996 when most consumers were still buying plane tickets through travel agents. Since then, travel agents have nearly become extinct along with many newspapers, local bookstores, and landline phones. But standards are still published and sold nearly the same way as they were twenty years ago despite their ever-increasing use in complex and often digital enterprise processes and supply chains.
There are numerous shortcomings with standalone PDF documents or files that burden engineers and companies with enormous amounts of wasted time, unnecessary cost, potential risk, and not least, frustration. The DoD has been able to distribute documents in an efficient and cost effective way using PDF, but the time has come to focus on how we can deliver documents as dynamic and interoperable digital data.
- Documents developed by Government Preparing Activities often reference documents developed by SDOs and vice versa. But the standards are not connected in any convenient user-friendly way; that is, users are unable to click easily from one document to another. They are not interoperable.
- Specifications and standards are more important than ever in many enterprise processes and supply chains, but integrating standards content is extremely challenging and risky. For example, engineers use equations, images, computer-aided design (CAD) drawings, tables of numbers, references, and sections of text contained in standards to prescribe vital steps in their work instructions, RFPs, manufacturing software, product lifecycle management (PLM) systems, and much more. Getting that information into these various derivative work products often requires re-keying by hand, copying and pasting, or recreating content – all of which takes time and introduces human error (i.e., risk).
- It is difficult for engineers to be aware of changes made to standards; furthermore, it is even more difficult to assess the impact of those changes on any derivative work products. When a standard is revised or its content is modified in a change notice, engineers have no way to know all the places where that standard’s information has been used throughout their enterprise or supply chain.
What if documents behaved more like the Internet of Things (IoT), where smart, connected products are revolutionizing the way we live?2 Emerging semantic technologies and cloud-based repositories can provide improved interoperability by enabling a concept in one document or application to “know” that it is connected to a concept in another document or application and to know why the connection exists. It also knows if the concept in the downstream document or application has changed at the source and can alert the user of the change. Using this approach, standards become interoperable Smart Connected Documents (SCDs) that can dramatically change the way engineering content is created and exchanged.
To illustrate the requirement for standards interoperability, let’s examine MIL-DTL-28748. This military specification defines fifty-eight characteristics for a family of rectangular connectors and is the source document for more than 2,200 National Stock Numbers (NSNs) found on 460 weapon systems (source: Weapon System Impact Tool (https://wsit.xsb.com)). MIL-DTL-28748, like many specifications, is not a standalone document. There are seventeen active supplementary slash sheets3 for this specification, each defining a particular subcategory of connectors. Just one of these slash sheets, MIL-DTL-28748/4F, references fifteen other documents, which in turn refer to another eighty-four documents. These references total more than 330 pages from different DoD and SDO sponsors, including ASTM International, SAE International, and ASME. But an engineer tasked with managing a single component may only need a small collection of facts hidden within these 330 pages. In fact, most engineers don’t need or read entire standards documents; they need answers to specific questions contained in just a few pages.
When a MIL document references a test method from an SDO industry standard, the user must leave ASSIST and go to another website, download the referenced document, and navigate to the appropriate section. Although finding and obtaining standards has become easier due to better search engines and aggregated collections, users still must expend time to gain access to the right standard and then more time to find the relevant information within the standard. This time-consuming effort is repeated for each reference as an engineer creates their work product. Making this information interoperable by linking the concepts within and between documents from different authorities and enabling engineers to embed these links in their work can reduce engineering parts management time by as much as twenty percent.4
Once a standard is acquired by an engineer, what does the engineer “hire” the specification to do? What job is she trying to accomplish beyond reading the document? According to the Outsell Survey of Engineering End-Users of Standards and Standards-Related Information,5 the most common uses of engineering standards are:
- Regulatory conformance;
- Design;
- Specification of materials or components;
- Definition of tolerance or performance; and
- Drawing.
Each of these uses requires the engineer to read through the network of documents and then cut-and-paste or manually re-enter content from these documents into various enterprise tools used to support these tasks. This process is often repeated by different entities (design, production, procurement, test…) within an organization and by different enterprises in the product supply chain. Each manual entry takes an incremental amount of time (often duplicating what someone else has already done), and introduces an opportunity for error; worse, it leaves the content disconnected from the authoritative sources, creating future configuration management challenges. If the authoritative information changes or is cancelled, awareness of that change does not automatically propagate to downstream users or applications. In other words, engineers take a snapshot of information during a moment in time, but as that information changes, the snapshot remains the same to everyone and everything that initially received it. Currently, there is no automated way of integrating standards-based content in such a way that downstream users or applications can be made aware that important information has been cancelled or changed.
Standards interoperability should enable an engineer to rapidly identify and integrate standards-based content with the tools and systems they use. This should work regardless of the standards author and be done with minimum manual rework, maximum accuracy, and traceability. Further, interoperability should enable the engineering end product (drawing notes, work instructions, test plans, etc.) to link directly back to specific concepts in the authoritative source. Those links should alert the using engineer of changes, take him or her directly to the “redline” for the changed concept, and allow the engineer to determine what steps, if any, need to be taken as a result of the change. In this way, engineering content is not just text, but evolves to become Smart Connected Documents:
- Concepts in Smart Connected Documents link directly to concepts in other documents regardless of author.
- Each concept is aware of why it is linked to another document (the link represents a relationship based upon the part, material, or process concept).
- Each concept ‘knows’ its status and the status of the document concept they link to (e.g., current, modified, or cancelled).
What to Do?
Today, there are two initiatives aimed at evolving standards documents into Smart Connected, Documents. According to the National Information Standards Organization (NISO),6 different SDOs have independently developed publishing standards governing the format of their documents. This variety in standards publishing makes interoperability between organizations difficult and increases integration costs. NISO is addressing this through a working group to create a standard for standards. This effort focuses on standardizing the format of standards documents across SDOs. It is based, in part, upon the open International Organization for Standardization (ISO) Standards Tag Set (STS).7
The Semantic Web for Interoperable Specifications and Standards (SWISS): The Defense Logistics Agency (DLA) research and development program is funding the development of an open standard and platform to convert product, material, and process specifications to interoperable SCD models. These models may be used to put together a combined, tailored, and complete part requirement that virtually includes precise concepts from the authoritative sources of referenced documents. These models may be exported into a standard MIL-STD-961 form to be read by people, or they could be queried through programming interfaces by other automated systems. SWISS is guided by a technical working group with twenty representatives from Government agencies, original equipment manufacturers (OEMs), and SDOs.
The SWISS project is developing “standards as digital models” that will cover about 50,000 pages of the most popular and frequently referenced Government specifications in ASSIST. The program is also working with major non-Government SDOs to convert their relevant specifications, and with design-centric OEMs to better understand their design processes. Additionally, the SWISS project is creating infrastructure to identify whether changes in referenced documents affect product requirements; for example, smart redlining that will allow quick visual comparison between any two revisions of a document.
Although efforts are currently underway to optimize the use of Extensible Markup Language (XML) to allow Government Preparing Activities to convert Microsoft Word® documents to machine and human readable formats, DoD is investigating ways to fully integrate SWISS with ASSIST so that ASSIST users will be able to easily navigate between documents in the SWISS network. In addition, SWISS digital models will be integrated with Microsoft Word so that Preparing Activities will be able to manage the authoritative version of a specification as a Word document and have it directly converted to a SWISS digital model.
The developers of SWISS are also working with OEMs and SDOs to convert their content into standards as digital models, enabling the information contained within the standards to be more easily integrated into enterprise processes and supply chains.
NISO STS and SWISS will enable engineers to link concepts in their engineering work products directly to the authoritative source for those concepts. The interoperability gained through these technologies will dramatically reduce engineering time to knowledge and make it possible to provide truly tailored, targeted, and engineered content that integrates both external and internal standards, supporting the workflow of end-users much more efficiently and effectively.8
Looking Ahead
I titled this article The Case for Standards Interoperability. I believe I’ve made the case—standards interoperability offers great advantages and most of them, frankly, seem pretty obvious. At a time when we’re connecting smart phones to thermostats, home security cameras and refrigerators, and when we’re also developing complex systems where sensors on cars interoperate with those on other cars, with GPS satellites, and with road hazard warning systems, making documents interoperable seems pretty simple in comparison. So why haven’t we already done this?
The reasons are not primarily technical. I don’t want to minimize the technical challenges—they are definitely not trivial. There are hundreds of thousands of documents and millions of references; they were created using different software and different rule sets; they are stored in different file formats at different locations all over the world; they are owned by any of several hundred different standards developing organizations; and the owners have different requirements for how their documents can be used. So just identifying, finding, and gathering the documents is a huge challenge. Electronically “reading” them, putting references in context, making the connections that will keep them version-aware, and getting them to talk to each other adds significant complication. But, there are other, non-technology related factors to consider.
When groups of engineers, scientists, academicians and others gather around the consensus table to develop a standard, they may argue and debate for hours over exactly the right way to express a concept or to qualify a requirement. The words are chosen carefully and the phrases are jam-packed with meaning. There is serious debate about the utility or appropriateness of plucking one subparagraph or one cell of a table from a standard without all of the surrounding material providing context, rationale, cautions, interpretation, direction about how to use results, etc. Does that kind of fractionating of an inherently very technical publication really serve well the designer, the engineer or other end user? If all those other words aren’t needed—why are they there? And why do we spend so much time getting them just so?
At least a part of the answer lies in showing things—a cell, a subparagraph, a drawing—in context. That was one of the features designed into SWISS early in its development. It was a way for the user to see not just the specific language called from the reference, but also the language surrounding it. Of course there is always a question about how much is enough. Does one need to be aware of not only the requirement paragraph and its parent, but perhaps also information from the preceding chapter, or from the forward, or an appendix? Where do you stop?
And there is a question, at least as vexing, of how to protect the revenue stream of those SDOs that produce the documents. Like it or not, many SDOs depend on the revenue from sale of their documents to operate the infrastructure that supports their development, maintenance, and publication. So when using SWISS to access a small piece of a document—how does a user get charged for that use, and how does the SDO get compensated? In a revenue model based on number of downloads, number of simultaneous users, or number of “peeks” at a document—does the user pay for a whole standard? Consider that SWISS can tell SDO EIEIO that user “Willie Fixit” wants to see standard 54321; that SWISS will check with EIEIO to determine if Willie has a license to the content; and if Willie is OK, then he proceeds to the content. If not, he is presented with a paywall. Is that fair to Willie? He only wants to see the one table at the bottom of page 352 – why should he pay for the whole 700 page standard? Does he get charged every time he looks? At the OEM level this kind of enterprise access model may work well, but how does it translate down through the supply chain? The derivative work needed by the sub-sub-sub-tier manufacturer of a fiber optic connector may be pulling information from dozens of standards from dozens of SDOs.
We can’t wait for perfect answers to every hypothetical situation—we must move ahead as best we can, solving problems as we go. In 2018 we plan to:
- Enable nearly 12,000 CAC users to have access to Mil and non-Government standards in SWISS format through conversion of the most frequently used ASSIST documents to SWISS, and expanded participation in SWISS by the most referenced SDOs. Where our DoD users have broad access to non-Government standards through enterprise-wide licenses, this will work seamlessly. Where our users do not have that access, they may face multiple paywalls each time they try to work with a standard or a work or inspection instruction built from references to multiple standards.
- We expect to validate tools for document conversion, and through improved interoperability with MS Word, to make it easier for DoD authors to self-publish their documents to SWISS.
The case has been made. We recognize that there are issues and questions to be resolved and we think that we have a pretty good handle on the issues, if not, yet, the solutions. The benefits are sufficient that we plan to continue to move forward. With people of good will and good intentions, I’m confident that solutions will emerge and that interoperable standards will become as ubiquitous as cell phones and as taken-for-granted as Google.
For more information about SWISS and its tool development, see the SWISS Web site at https://swiss.io/; The NISO Standards Tag Suite (STS) is published at https://groups.niso.org/apps/group_public/download.php/18492/Z39.102-2017.pdf.
About the Author
Gregory E. (Greg) Saunders is the Director of the Defense Standardization Program Office, the Defense Secretary’s Executive Agent for the Defense Standardization Program. He is responsible for policies and procedures governing development and use of Military Specifications and Standards, Qualified Products and Manufacturers Database, and the use of voluntary consensus standards, and represents the Department in standardization matters with other Government agencies, NATO, and industry. He also oversees the Government Industry Data Exchange Program (GIDEP) and DoD activities to mitigate the impact of diminishing manufacturing sources. Mr. Saunders is the vice-chair of the Defense Standardization Council chaired by the Deputy Assistant Secretary of Defense for Systems Engineering. The Council provides overall, top-level policy guidance for the DSP.
Mr. Saunders is a past Chairman of the Board of Directors of ASTM International, served on the Board of the American National Standards Institute (ANSI) and is a Fellow at SAE International where he served on the Board of Directors, served three years as the Aerospace Vice President and chaired both the Aerospace Council and the Technical Standards Board. He is the U.S. representative to two NATO Committees, and chairs NATO’s Standardization Management Group. He also represents the DoD on the Interagency Committee on Standards Policy.
Mr. Saunders has been honored to receive numerous awards, recognitions and commendations to include the Vice President’s Golden Hammer Award, the Department of Defense Civilian Service Award, the Joint Meritorious Unit Award, SAE’s Medal of Honor, ANSI’s Howard Coonley Medal and their Meritorious Service Award, ASTM’s William T. Cavanaugh Memorial Award, the SAE Aerospace Chair Award, the Standards Engineering Society’s Leo B. Moore Medal of Honor, the Silver Star of the Polish Army, and industry’s Equal Partner Award.
1 Organisation for Economic Cooperation and Development; https://www.oecd.org/tad/benefitlib/1955309.pdf
2 Michael E. Porter and James E. Heppelmann: Harvard Business Review October 2015: How Smart Connected Products are Transforming Companies https://hbr.org/2015/10/how-smart-connected-products-are-transforming-companies
3 Specification Sheets (informally known as slash sheets because they are identified with the specification number followed by a slash and another number, e.g. 28748/4) are documents that specify requirements and verifications unique to a single style, type, class, grade, or model that falls within a family of products described under a general specification.
4 Anecdotal claims from interviews with OEMs as well as test plan creation benchmark study by XSB, Inc.
5 Jo McShea and James Erickson: Outsell, Inc. December 2014: Engineering End-Users of Standards and Standards-Related Information; https://www.outsellinc.com/search/d7entity/47908
6 National Information Standards Organization (NISO): http://www.niso.org/workrooms/sts/
7 ISO Standards Tag Set (STS): http://www.iso.org/schema/isosts/
8 Jo McShea:Outsell, Inc. April 2016: Standards: 2016 Market Size, Share, Forecast and Trends; https://www.outsellinc.com/search/d7entity/51630