Not too long ago, two main deliverables fully described the design of a part: the drawing and the specification. The drawing provided a geometric representation of the part both nominally and from a manufactured tolerance perspective. The specification was a document that acted almost as a catch-all for everything else.

In the past few decades, the technologies used to create, and even make it obsolete, has changed dramatically. Drafting gave way to 2D and 3D modeling and the drawing almost became an afterthought. Visualization tools have made it easier to go paperless… or at least less paper dependent. Model based initiatives have even let organizations move away from 2D completely.

But what about the specification?

In this post, I’d like to cover how advancements in technologies have affected the specification, for good and for bad. Let’s dive in.

Specification Components are Increasingly Federated

Specifications have always been a deliverable that engineers have used for a wide variety of purposes. For some organizations, it was minimal and contained very little information about the part. For other organizations, they were terribly exhaustive. To start to understand how technology has affected the specification, it makes sense to list out the different components of a specification and what modern technologies are used to create and manage them now.

Part Information: Traditionally, all sorts of different characteristics that describe a part would be captured in the specification. This could be the date the part was introduced, the identification of the materials used, the manufacturing processed used and more. Today, this information is far more likely to live in a variety of different enterprise systems like PDM, PLM and ERP than any document.
Configuration Tracking: Managing the configuration information about parts also traditionally lived in the specification. This included the part’s effectivity, it’s superseded and superseding items as well as which product configurations in which it was used. This is essentially the part level perspective of BOM management. Today, you see PLM and ERP systems managing this information more than anything else.
Requirements and Functions: Another set of information traditionally managed in documents are the requirements and functions that the part must fulfill. Both requirements and functions are often defined and used as part of the system engineering process. These things are now tracked and controlled with requirements management or system engineering capabilities that are part of a standalone system, a PLM system or even a CAD application.
Calculations and Numbers: Another big piece of engineering a part has been to perform calculations to predict performance or size certain aspects of the part. Engineers would take a factor of safety into account and plan accordingly. This information now is more likely to exist in an individual file created by calculation software or CAE applications.
Failure Modes and Effects: Another design activity that was commonly documented in specifications was the thought process of identifying how a part could fail and then the resulting effect it would have on the product. Understanding that sequence of events let engineers design in failsafes and redundancy in their design. The designation of those failure modes and their effects are often still captured in documents today.

The Implications of Specification Federation

OK. So what’s my point here? It’s fairly simple.

All of the information represented in the list above is now spread out across many different software applications and systems. Now that, in and of itself, isn’t necessarily bad. As each of these things change, they can be tracked with their own versions and iterations. The upside is that you can track a requirement that has changed fifteen times separately from a calculation that has changed twice. That’s goodness.

The problem in my eyes is that there hasn’t been any analogous equivalent to the specification. Even for PLM systems, which may house a couple different types of this information, this information often is not aggregated into a single place that an engineer can treat like a specification. Furthermore, editing this information often requires the engineer to navigate to each of these separate items individually. But for information spread across many systems and applications, the engineer has to log in or open up numerous files to get the information they need or to make the changes that are required.

Summary and Questions

Let’s start with the recap.

Years ago, engineering used drawings and specifications to fully define a part. Drawings primarily offered a geometric definition. The specification often was used to capture everything else.
Numerous different software applications and systems have emerged to manage the different components that went into a specification. These tools range from PDM, PLM and ERP systems to CAD, CAE and calculation software applications.
As a result, engineers must visit various different software systems and applications to get the complete picture of the product that the specification used to offer. Engineers need some means to aggregate this information.

Alright, those are my thoughts. What are you using for specifications today? How to you create an integrated view across different software applications and systems? Sound off. Would love to get your perspective.

Take care. Talk soon. And thanks for reading.