How does Item Revision State differ from Item Lifecycle Phase?

PDXpert product lifecycle management software supports various data revision approaches, including traditional pre-production numeric and production alphabetic formats. Nonetheless, this topic explains why these traditional approaches should be considered obsolete. We describe how using only one revision format (alphabetic or numeric), coupled with PDXpert PLM software's built-in item lifecycle phase attribute, provides fine-grained control over product life cycle business rules while reducing the cost and risk of managing item revisions. We believe that using a single revision format regardless of the item's lifecycle phase is current best practice.

Item records, whether for document or part, must have one or more revisions. An item revision represents the technical content at a specific point in time; a released revision represents an item's approved technical content at a point in time.

Separately, items have a lifecycle: they're conceived, designed, prototyped, validated, produced, serviced, disposed of, and (when no longer commercially viable) declared obsolete.

In PDXpert PLM software, an item's revision release state and the item's lifecycle phase are independent attributes. Multiple item revisions may share a common lifecycle phase, and a particular item revision can move through several lifecycle phases.

Document and part revision states

The revision state informs everyone: "Can this specific revision be used now?"
Only a Released state says "Yes".

Revision states reflect the availability, or "readiness for use", of a specific item revision. PDXpert PLM software defines exactly 3 release states for any item revision:

1. Pending (unreleased, pre-release, created, originated, etc.)
2. Released (issued, authorized for use, active, in-use, etc.)
3. Canceled¹ (superseded, obsolete, invalidated, void, removed from use, inactive, etc.)

At any point in time, each item in PDXpert software may have no more than one Pending revision and no more than one Released revision, and zero or more Canceled revisions.

These business rules are universal, and applied regardless of the product data management process used:

• Users can discard an item revision in Pending state without effect or penalty.
• Users can use the revision in Released state according to the appropriate item lifecycle business rules.
• Users may not use a revision in Canceled state, and the revision must be retained to provide a historical reference.

Note that the only state that's relevant for production purposes is the Released state. And there are some corollaries:

• Each released or canceled item revision must have an associated implementing change (typically called an "engineering change notice" or "engineering change order"). A pending revision need not be associated with a change.
• For an item structure ("bill of materials"):
  • A child component's pending revision may only appear on an assembly's pending revision. An unreleased child revision can never be used on a released or canceled parent assembly revision.
  • Released items can appear as child components on a released parent assembly revision, as well as on pending and canceled revisions of parent assemblies.
  • A canceled item revision may only appear on a canceled parent revision.

The three release states represent the simple life cycle of a specific item record revision, but do not say anything about what business rules apply to the item while the revision is in its released state.

Document and part lifecycle phases

The lifecycle phase informs everyone: "Can this released revision be used without restriction?"
Only a Production (or its equivalent) phase says "Yes".

The item lifecycle phase identifies a set of company-specific business rules that are used as the item moves from conception through to production, and is finally retired.

Any number of item lifecycle phases can be defined, and each may be applied to documents or parts or both. PDXpert software generally follows the enumerations² in the IPC-2570 standards, which other PLM software suppliers also use. These phases are specified by IPC-2570 but aren't defined, presumably because each organization will create its own set of business rules.

Here are a few examples of item lifecycle phases with possible business rules:

• Preliminary Document intended only for internal use. It is not approved for external distribution and may not be used to acquire parts.
• Prototype Information and the items created from it may only be used in very limited quantities to validate the design and to begin production tooling, fixtures and processes.
• Pilot Part may be acquired in limited quantities for proof-of-concept production, product support, and field testing. Depending on the product, you may include (potential) customers, and may either deploy or recover pilot units after testing is complete.
• Production Product information may be used without restriction to meet customer demand.
• Service-only Part may not be used for new designs. Part may only be purchased for servicing previously produced items.
• Obsolete Item may not be used for any purpose.

Prototype ("alpha") and Pilot ("beta") phases in particular are often assigned more specific business rules regarding maximum quantity permitted, design approvals required, and tooling and fixture decisions. Contractual obligations or marketing policies may dictate business rules, such as setting tight inventory stock thresholds and tooling availability, for items at a Service-only phase. The Obsolete phase may incorporate disposal & recycling business rules, and inventory write-off procedures. Clearly, each company will approach the set of lifecycle phase definitions according to product complexity, industry norms, marketing considerations and internal accounting policies.

Item lifecycle business rules are only applied by the organization and its supply chain partners to currently-released item revisions, and are irrelevant to pending and canceled revisions.

Benefits of keeping revision values and lifecycle phases separate

In many older engineering document control processes, an engineering drawing revision did double duty, indicating both a specific technical iteration and the business rules currently applicable to the engineering drawing. Numeric ("01"), dash ("-"), and date ("22 Oct 1992") formats were recommended³ prior to production release, and alphabetic revisions ("A") were used for production revisions. In the pre-computer era, this was understandable because methods for informing an item's user of its lifecycle phase were quite limited and lifecycle business rules weren't terribly sophisticated.

However, one paid a significant price for this scheme:

1. Moving the product into production required a sudden additional burst of resources to modify every engineering drawing to change the pre-production revision format to production format. Regardless of product complexity, the last thing you need is an empty exercise that runs every drawing though the CAD system one more time to update the revision block. It's a time-consuming distraction that adds little value and, with an unnoticed flick of the mouse, can actually damage previously-validated information.
2. There's a severe limit to the number of lifecycle phases that could be represented by varying revision formats (dates, numbers, letters and, well, Roman numerals?). In general practice, there's no way to distinguish any lifecycle phase after production.
3. Within a specific lifecycle phase, changing a drawing revision always indicated that the technical contents of the document had changed. But changing the revision format to indicate a new lifecycle phase left an ambiguity: did the document contents change at the same time as the lifecycle phase changed?

By separating the item revision from its lifecycle phase, PDXpert PLM software avoids these difficulties. Importantly, a single revision format can now be used through the item's lifecycle. Incrementing the revision value exclusively indicates an interchangeable change to a physical part, or a change which affects only the document contents. The engineering document process can also support an unlimited number of lifecycle phases anywhere between item concept and obsolescence, with each phase having a distinct set of business rules.

While PDXpert software can correctly increment separate pre-production and production revision formats (and can support manual revision formats like dash and date), there is no longer any reason to maintain more than one revision format over the life of an item.

Notes

1. Items no longer in use may be superseded (replaced with a newer item) or obsolete (not replaced); see Samaras, Thomas: Configuration Management Deskbook, AACI (1988), page 137. We looked for generic term to accommodate both concepts and settled on canceled. Although the IPC-2570 standards had some influence on PDXpert's nomenclature, unfortunately "Obsolete" is one of the Item element's Global Life Cycle Phase Code enumerations (see IPC-2578 section 4.1). We adopted Pending/Released/Canceled for revision states rather than Pending/Released/Obsolete because we wanted to avoid confusion between the invalidated revision state and the "no longer in use" item phase. Acseni PDM used the terms Pending/Issued/Void in the same manner.
2. IPC-2578 globalLifeCyclePhaseCode (section 4.1) and globalManufacturerPartStatusCode (section 9.1).
3. See, for example, Watts, Frank: Engineering Document Control Handbook, Noyes Publications (1993), page 132.

This application note was relevant to the PDXpert software release that was current at time of publication. Product changes since that time may affect its utility. We'd be happy to assist you in assessing the applicability of this note to your situation.