Generic Requirements for Electronics Manufacturing Supply Chain Communication Product Data eXchange (PDX) IPC 2571 Generic Requirements for Electronics Manufacturing Supply Chain Communication – Produ[.]
IPC Documents
This standard includes provisions referenced in the following documents, which are subject to revision Parties entering agreements based on this standard should consider using the latest editions of the specified documents.
IPC-T-50 Terms and Definitions for Interconnecting and Packaging Electronic Circuits
IPC 2510 Generic Computer Aided Manufacturing Descriptions for Printed Boards and Printed Board
IPC 2576 Product Data eXchange – Sectional Requirements for Electronics Manufacturing Supply
Chain Communication of As-Built Product Data
IPC 2577 Product Data eXchange – Sectional Requirements for Supply Chain Communication of
Manufacturing Quality Assessment IPC 2578 Product Data eXchange – Sectional Requirements for Supply Chain Communication of Bill of Material and Product Design Configuration Data
RosettaNet Documents
The following are RosettaNet Partner Interface Process documents that relate to this standard, and reflect an effort made by both organizations towards harmonization
RosettaNet PIPs 2C1-10 (IPC2578) Product Design Information
Segment 7A Design Transfer Segment 7C Distribute Manufacturing Information
OAG Documents
OAGIS Open Applications Group Interchange Specifications will be used to harmonize with this standard and will be incorporated in later revisions of this standard.
RFC Documents
RFC 1950 ZLIV Compressed Data format Specification 3.0
RFC 1951 DFLATE Compressed Data Format Specification Version 1.3
RFC 1952 GZIP file format specification 4.3
The standard defines a Product Data eXchange (PDX) package using a single XML file named "pdx.xml," which must include a single ProductDataeXchangePackage element and may optionally incorporate additional elements as specified This XML file can also reference external attachments and may include elements from other IPC 257x PDX standards.
A Product Data eXchange (PDX) package can consist of a single XML file along with multiple external attachments To facilitate communication, these files can be compressed into one package, following Internet RFCs 1950 to 1952 This compression not only consolidates the files for easier delivery but also significantly reduces their size, which is particularly beneficial for large XML files that contain repetitive data The resulting compressed file, which includes the pdx.xml and any attachments, is designated as a Product Data eXchange file with a ".pdx" extension and a MIME type of application/x-pdx While compression is optional and not mandated by the specification, it must be agreed upon by the sending and receiving partners as part of their transport layer for exchanging Product Data eXchange packages.
The Product Data eXchange (PDX) package necessitates the inclusion of an internal Document Type Definition (DTD) file, which must be fully integrated into the pdx.xml file This document contains the DTD at its conclusion Alongside the required XML process instruction of or , the pdx.xml file also features two additional process instructions.
The article specifies the version of the Product Data eXchange standard used in the package, indicated by Additionally, it notes the software version utilized for package creation, as shown by .
Modeling Diagram Occurrence Indicator Meanings
Occurrence indicators are used within element content models to specify how many times an element may appear at a given location The indicators available to schema developers are listed below:
Meaning none The element must appear once and only once
? The element (or group of elements) may appear zero or one times
The element is optional, but is only allowed to appear once
+ The element (or group of elements) must appear one or more times
The element is required to appear at least once, but multiple consecutive occurrences may be present
* The element (or group of elements) may appear zero or more times
The element can appear as many times consecutively as needed, or even zero times
The PDX standard suite includes graphics and a table of attribute descriptions to enhance understanding In cases where there is a conflict between the XML DTD and an image or description, the DTD should be regarded as the authoritative source.
4 Pictorial Representation of IPC2570 Series
The following illustrations provide a graphical representation of some of the primary elements contained in the suite of Product Data eXchange standards:
Product Instance
Inclusion of Linked Objects
To grasp the concepts of ID and IDREF, it is essential to consult the XML W3C standard These identifiers are unique to each PDX package and can be likened to virtual flat file pointers It is important to note that ID and IDREF hold no significance beyond the context of the PDX package.
Objects are interconnected through references, such as the manufacturerContactUniqueIdentifier, which links to a contactUniqueIdentifier using IDREF and ID These linking attributes, defined in the Product Data eXchange diagram, are of type IDREF It is essential that the ID field is always populated to specify the ID of the referenced object, ensuring that every IDREF has a corresponding ID entry.
The contact information exchanged under this standard differs from that in RosettaNet headers, focusing on roles such as engineering manager and purchasing manager rather than IT contacts for transaction delivery This method allows for the bulk transmission of entire contact lists, including referential information about all contacts between trading partners, facilitating the agreement on roles, responsibilities, and necessary approval contacts Approval requirements and tracking fall within the workflow layer, which is outside the scope of this standard and should be managed through transport standards like RosettaNet or OAG, or by solution providers and trading partners through mutual agreements Optional attributes are available to support the workflow layer.
Attachments
The Product Data eXchange package can contain essential attachments that enhance the product content, including various file types such as Universal Resource Identifier (URI) references, XML/DTD documents, XSL files, drawings, Gerber files, and test specifications These attachments can be managed in multiple ways.
The Product Data eXchange package includes an attachment, indicated by the "isFileIn" attribute set to "yes," which signifies that the product data contains a URI-referenced attachment It is crucial to communicate effectively, as the contents of the URI are not controlled within the package and may change independently Conversely, if the "isFileIn" attribute is set to "no," it indicates that while the product data references an attachment, the attachment itself is not included in the package.
The metadata associated with the attachment is referenced via FileName, but the attachment itself is not included in the PDX package The "isFileIn" attribute is set to "no," indicating that while the product data includes an attachment, it is not part of the package This feature is useful when the sender is aware that the recipient already possesses the attachment.
Missing Required Attributes
When generating a Product Data eXchange package, it is essential to set any required attribute without a value to an empty string ("") to prevent rejection by applications utilizing a validating XML parser.
Establishing workflow rules with error level checking is essential, encompassing categories like critical, required, suggested, split, optional, and obsolete, while avoiding the use of the "isolate" category Effective communication should focus on logging, alerts, escalation, tracking, and resolution Additionally, defining roles within the contact element between partners is encouraged to enhance communication within the workflow layer, although this aspect is outside the scope of the current standard.
Avoid Data Duplication in Product Data eXchange Package
In a Product Data eXchange package, shared objects, such as sub-assemblies, should not have duplicated data, including metadata and attachments For instance, if objects A and P both utilize sub-assembly C, the data for C should only be included once in the package It's crucial to note that any modifications to a part or assembly necessitate updates to the higher levels to ensure uniqueness for manufacturing clarity While supply chain partners may agree that certain changes do not materially impact the business or engineering aspects, this practice is discouraged to maintain a complete audit trail for warranty purposes.
The decision to adopt a flat structure for defining Item, rather than an embedded or recursive format, allows for a single instance of an object to be included in a PDX package This approach enables the same instance to be referenced in multiple locations, enhancing efficiency and organization.
Avoiding data duplication is a best practice, but the Product Data eXchange standard does not mandate it, and including duplicated data in a Product Data eXchange package is not a violation Certain government and industry standards necessitate a comprehensive "line by line" transmission of information, which may lead to data duplication in lower subsections of the Bill of Materials (BOM) Consequently, the standard allows for the transmission of fully duplicated subsections of the BOM to comply with these established practices.
The package enables the transmission of complete contact information and a full Bill of Materials (BOM) with essential buyer elements for RFQ submissions Additionally, AML vendor database information can be transmitted in bulk, facilitating the loading of catalog information for components and their suppliers The IPC257x series offers cross-reference information capabilities that can be utilized by specific applications Furthermore, the AdditionalAttributes element allows for the transmission of extra purchasing details, including pricing, which, while not covered by this standard, supports its use in RFQ and Quote Response scenarios.
By sending bulk load information separate, only updated or changed – delta – information need to be transmitted unless an error is encountered.
Excluding data from the Product Data eXchange package
The Product Data eXchange standard enables the transmission of incremental change data or specific subsections of the element tree, eliminating the need to replicate the entire Bill of Materials (BOM) with each Product Data eXchange package.
When submitting an Engineering Change Order (ECO) for a specific product, it is not required to send the complete Product Data eXchange (PDX) file to the implementing agency if they already have the data in their system Instead, only the modifications to the PDX document need to be provided.
When excluding data from a Product Data eXchange package, the sender must ensure that the remaining package is self-sufficient and comprehensible to the recipient This includes the possibility of sending BOM subsets, BOM mark-ups, or AML mark-ups without all associated data It is crucial for the sender to provide sufficient information within the Product Data eXchange package to clearly identify the communicated change and its relationship with all affected elements.
BOM changes, AML changes, schematic changes, and other attachments must be interconnected and tagged with ECO identification as per the Product Data eXchange standard Sub-assemblies within a BOM can be transmitted independently, allowing Electronics Manufacturing Services providers to receive only the necessary components without the entire BOM This approach enhances efficiency, especially during negotiations between the design originator and the manufacturer of sub-assemblies, as lengthy processes can hinder reaching a consensus.
Best practices dictate that a complete resend of the BOM subsection or relevant information should occur upon encountering an error during the processing of incremental changes, with all trading partners notified An advanced solution would involve systems automatically resending and comparing data higher in the BOM tree structure until successful database synchronization is achieved, minimizing the need for human intervention unless specified in the workflow Refreshing a complete database or subsection database is not considered a violation of this standard.
Format of Date/Time Fields
The preferred format for date and time data is a string that adheres to the W3C datetime format, representing the current date and time Various formats specified by W3C are permissible for use.
Complete date: YYYY-MM-DD (eg 1997-07-16)
Complete date plus hours and minutes: YYYY-MM-DDThh:mm TZD (eg :1997-07-16T19:20+01:00)
Complete date plus hours, minutes, and seconds: YYYY-MM-DDThh:mm:ssTZD
Complete date plus hours, minutes, seconds and a decimal fraction of a Second
YYYY-MM-DDThh:mm:ss.sTZD(e.g 1997-07-16T19:20:30.45+01:00)
MM = two-digit month (01=January, etc.)
The format for representing time includes a two-digit day of the month (DD) ranging from 01 to 31, followed by a two-digit hour (hh) in a 24-hour format, where am/pm is not permitted Next, it specifies two digits for minutes (mm) and seconds (ss), both ranging from 00 to 59 Additionally, a decimal fraction of a second can be represented by one or more digits (s).
TZD = time zone designator (Z or +hh:mm or -hh:mm)
The current version of the Product Data eXchange standard defines all attributes as character strings due to XML DTD constraints, preventing the enforcement of recommended date/time formats Consequently, it is the responsibility of applications generating Product Data eXchange packages to voluntarily follow these guidelines Best practices are illustrated through diagrams that emphasize robust data typing in Schema Development, supported by accompanying tables.
isTopLevel Attribute
The isTopLevel attribute signifies the role of an object, such as item, ManufacturerPart, or SupplierPart, within a Product Data eXchange package It enables Product Data eXchange parsers to efficiently identify the top-level item in an assembly.
The ProductDataeXchangePackage element is essential for every Product Data eXchange file, serving as the root element that encapsulates the entire transmission It provides a comprehensive description of the package and its contents, and it is important to note that each ProductDataeXchange package can contain only one ProductDataeXchangePackage element.
The article outlines key attributes for a package, including the required unique identifier, thisDocumentIdentifier, which should be universally unique without a defined format It also specifies the mandatory timestamps for package generation and modification, noted as thisDocumentGenerationDateTime and thisDocumentModificationDateTime, respectively, with suggested formats available in section 5.6 Additionally, it mentions optional attributes such as originatedByContactName, identifying the package's originator, and originatedByContactUniqueIdentifier, which refers to the originator's contact element Lastly, the packageType attribute is implied, with recommended values including Manufacture.
ChangeRequest | ChangeOrder | ChangeNotification | Test | Kit | BuildReport description CDATA #IMPLIED Description of the package dataSource CDATA #IMPLIED Source of the package thisDocumentCopyright CDATA #IMPLIED Copyright information of the package
The history element holds a collection of HistoryItem elements that together describe the entire history of the related object.
HistoryItem
The HistoryItem element describes a specific historic action
The article outlines key attributes related to an action taken on an object, including the required action type (Add, Modify, Delete), the revision identifier, and the originator's name and contact ID It specifies the modification date as a required field, while the history item status and additional details about the action are optional Furthermore, it allows for free-form comments regarding the event, providing a comprehensive overview of the action's context.
The attachments element contains all the attachment elements associated with a specific object.
Attachment
The attachment element serves as a pointer to a file, which can be accessed via a URL or included within the Product Data eXchange zip file If the file is compressed in the package, the FileName will indicate the name of the file; otherwise, it will provide the complete URL of the file's location Each object is associated with a single attachment element for every related file.
The article outlines two key attributes: the "referenceName," which is an optional user-defined file name (e.g., file.doc), and the "universalResourceIdentifier," a mandatory URI that serves as a comprehensive network-centric identifier for a resource, as specified in the IETF RFC.
The PDX package requires the use of the file://filename notation to reference a contained file Additionally, the fileIdentifier is a unique identifier for the file, which may serve as a key to access it.
This field is applicable when multiple attached files share the same filename The versionIdentifier attribute indicates the file's version, while the fileSize attribute specifies the size of the file Additionally, the checkSum attribute utilizes the MD5 message digest algorithm as outlined in RFC 1321.
The `isFileIn` flag indicates whether a file is included in the Product Data eXchange package, with a required value of "Yes" or "No." The `description` field provides an optional file description, while the `globalMimeTypeQualiferCode` specifies the MIME type, which can be referenced at [IANA](http://www.iana.org) for a comprehensive list of types.
The contacts element is used to hold a collection of contact elements.
Contact
In the context of RosettaNet RNIF 1.x or 2.0, each contact signifies an individual or entity, with a key distinction being the assignment of additional roles beyond just information technology For instance, when trading partners need to implement an Engineering Change Order (ECO), various personnel within their organization are tasked with reviewing the ECO, agreeing on the implementation date, and assessing the impact on areas such as purchasing, test engineering, and production Consequently, a contact may assume the role of Engineering Manager, whose digital signature is essential for the ECO's approval.
The workflow of Engineering Change Orders (ECOs) is not covered by this standard; however, it is expected that implementers will utilize role information to monitor the approval process For instance, the Engineering Manager may designate alternate individuals to sign off on approvals in their absence, indicated by setting the isAlternate attribute of the GroupRole entity to "yes." Additionally, a person can hold multiple roles; for example, the Test Engineering Manager may possess veto power over an Engineering Change (EC) but is not obligated to sign Furthermore, the Engineering Test Manager can serve as the alternate signoff designee for the Engineering Manager role, which requires approval prior to the implementation of an ECO.
The optional Public Digital Certificate can include multiple entries for the signoff process, as individuals may utilize two or more distinct certificates from various trading partners.
The article outlines essential attributes for contact information, including the required contactIdentifier and contactUniqueIdentifier, which serve as unique references for each contact It emphasizes the importance of the contactName, which identifies the individual within the organization Additional attributes such as addressLine1, addressLine2, and addressLine3 provide details of the physical address, while cityName and regionName specify the city and state or province The globalCountryCode indicates the country using the ISO 3166-1993 standard, and the nationalPostalCode represents the geographic location through a postal code Lastly, the telephoneNumber attribute allows for numeric contact via phone.
Attribute Name Type Required? Description emailAddress CDATA #IMPLIED email address universalResourceIdentifier CDATA #IMPLIED Company’s URI contactStatus CDATA #IMPLIED Status – suggest use “active”, “alternate”,
The "isTopLevel" attribute indicates whether a contact is at the top level of the PDX package, with a default value of "No." If set to "Yes," it signifies that the contact is a primary element; if "No," the contact is part of another object Additionally, the globalPartnerClassification is relevant in this context.
(Carrier | Distributor | EndUser | EndUserGovernment | Financier | Manufacturer |
Retailer | Shopper | FreightForwarder | Broker | CustomsBroker | Warehouser | DistributionCenter | ContractManufacturer |
#IMPLIED Code identifying a partner’s function in the supply chain Default is Unspecified globalPartnerClassification
If the globalPartnerClassificationCode attribute is set to "Other," provide a more descriptive value in this field If it is not set to "Other," leave this field blank.
The CDATA #IMPLIED code specifies a partner's role within the supply chain The globalLocationIdentifier is a unique location identified by the DUNS +4 number Additionally, the postOfficeBoxIdentifier represents a proprietary identity for a physical address at a post office, specifically designated for mail receipt.
ContactRoles
ContactRole
Attribute Name Type Required? Description groupRoleDescription CDATA #IMPLIED Optional description or may be used to further subdivide grouping classifications
GroupRole
The article outlines the attributes for a role classification between trading partners, specifying that the "role" attribute is required and must be defined as a CDATA type It also includes the "isAlternate" attribute, which indicates whether the contact serves as an alternate approval or disapproval role, with a required value of "No" for the primary role Additionally, the "description" attribute, which is implied, provides further details about the role.
PublicDigitalCertificate
A digital certificate may be used to encrypt an attachment, for non-repudiation of approval/disapproval, and allows embedding of security within the PDX package exchange
The article outlines the attributes related to digital certificates, including the required public digital certificate and the optional trusted root, which specifies the issuer's name Additionally, it mentions the trusted root URI, which serves as a verification and validation resource for the certificate.
PDX recognizes that a single standard cannot fulfill the diverse and evolving needs of all organizations To address this, it incorporates AdditionalAttributes and AdditionalAttribute elements, which facilitate user-defined extensions for any Product Data eXchange entity The AdditionalAttribute element specifies an individual new attribute, while AdditionalAttributes allows for the organization of these new attributes into groups.
Using these elements effectively creates a customized version of the standard, which may not be compatible with standard Product Data eXchange implementations Therefore, users should exercise caution when utilizing expansion mechanisms and are encouraged to suggest any desired enhancements to the IPC Product Data eXchange committee.
Item characteristics such as package, resistance, etc attributes are not to be handled by AdditionalAttributes, but are to be handled by the characteristics element defined in IPC 2578
All entities may have zero or more child AdditionalAttribute elements The AdditionalAttributes element is a collection of AdditionalAttribute elements
Attribute Name Type Required? Description groupLabel CDATA #REQUIRED Label for a group of grouped additional attributes
AdditionalAttribute
Each AdditionalAttribute element represents a non-standard, user-defined attribute
Attribute Name Type Required? Description name CDATA #REQUIRED The attribute name value CDATA #REQUIRED The attribute value dimension CDATA #IMPLIED The dimension (units) of the value dataType (String |
Boolean | Float | Double | Decimal | DateTime | Binary | UriReference | Other )
The attribute "dataTypeOther" is of type CDATA and is optional It should be used to provide a more descriptive value if the "dataTypeCode" attribute is set to "Other." If "dataTypeCode" is not set to "Other," this field should remain blank Additionally, the "description" attribute, also of type CDATA and optional, is meant for providing a description of the attribute.
The AlternateIdentifiers element holds a collection of AlternateIdentifier elements that provide an optional, alternative mechanism for referring to an item or part.
AlternateIdentifier
The AlternateIdentifier element facilitates the representation of an item associated with multiple part numbers (itemIdentifier), which is essential for businesses that, due to acquisitions or industry standards, have identical items linked to various part numbers A description is provided to aid in the classification of the alternate identifying number.
Attribute Name Type Required? Description alternateIdentifierNumber CDATA #REQUIRED The identifying number description CDATA #REQUIRED The description of the numbering scheme from which the alternateIdentifierNumber is derived
This specification employs a Document Type Definition (DTD) rather than XML Schemas, as the XML Schema specification was not fully established at the time of writing Future iterations of Product Data eXchange XML definitions are anticipated to utilize XML Schema.
The following is a master DTD that includes all elements from the IPC-2571, IPC-2576 and IPC-2578
Other ) #IMPLIED dataTypeOther CDATA #IMPLIED description CDATA #IMPLIED >
Other ) #IMPLIED globalLifeCyclePhaseCodeOther CDATA #IMPLIED description CDATA #IMPLIED >
manufacturerContactUniqueIdentifier IDREF #IMPLIED globalManufacturerPartStatusCode (Approved |
Other ) #IMPLIED globalManufacturerPartStatusCodeOther CDATA #IMPLIED globalPreferredStatusCode CDATA #IMPLIED description CDATA #IMPLIED manufacturedBy CDATA #IMPLIED >
The article discusses the attributes of an attachment, including its reference name, universal resource identifier, file identifier, version identifier, file size, checksum, and whether the file is present It also highlights the description, global MIME type qualifier code, and the modification date of the attachment.
Other ) #IMPLIED globalBillOfMaterialTypeCodeOther CDATA #IMPLIED notes CDATA #IMPLIED billOfMaterialItemIdentifier CDATA #IMPLIED billOfMaterialItemUniqueIdentifier IDREF #IMPLIED itemQuantity CDATA #IMPLIED globalProductQuantityTypeCode (PerAssembly |
Other ) #IMPLIED globalProductQuantityTypeCodeOther CDATA #IMPLIED description CDATA #IMPLIED proprietarySequenceIdentifier CDATA #IMPLIED >
Other ) #IMPLIED globalEngineeringChangeStatusCodeOther CDATA #IMPLIED changeStatusDate CDATA #IMPLIED changeType CDATA #IMPLIED changeSubType CDATA #IMPLIED changeOriginationDate CDATA #IMPLIED
Other ) #IMPLIED globalLifeCyclePhaseCodeOther CDATA #IMPLIED releasedDate CDATA #IMPLIED incorporatedDate CDATA #IMPLIED effectiveDate CDATA #IMPLIED obsoleteDate CDATA #IMPLIED changeType CDATA #IMPLIED proposedRevision CDATA #IMPLIED globalEngineeringChangeStatusCode (IssueIdentified |
Other ) #IMPLIED globalEngineeringChangeStatusCodeOther CDATA #IMPLIED description CDATA #IMPLIED >
The contact information includes essential attributes such as a unique identifier, contact name, and optional details like address, city, region, and country code Additional fields may contain telephone and facsimile numbers, department, business name, email address, and a universal resource identifier The contact status and classification as a top-level or global partner are also specified, ensuring comprehensive data management for effective communication and organization.
Other ) #IMPLIED globalPartnerClassificationCodeOther CDATA #IMPLIED globalPartnerSubClassificationCode CDATA #IMPLIED globalLocationIdentifier CDATA #IMPLIED postOfficeBoxIdentifier CDATA #IMPLIED >
Characteristics? , AlternateItems? , SerialNumbers? , AlternateIdentifiers?)>
Other ) #IMPLIED globalLifeCyclePhaseCodeOther CDATA #IMPLIED globalProductTypeCode CDATA #IMPLIED itemClassification CDATA #IMPLIED revisionIdentifier CDATA #IMPLIED versionIdentifer CDATA #IMPLIED proprietaryProductFamily CDATA #IMPLIED category CDATA #IMPLIED globalProductUnitOfMeasureCode CDATA #IMPLIED makeBuy (Make |
The article discusses various attributes related to product revisions, including the minimum shippable revision, release and incorporation dates, and whether serialization and certification are required It also highlights the owner's name and unique contact identifier, as well as whether the product is classified as top-level Each attribute is essential for understanding the product's specifications and requirements.
Other ) #IMPLIED globalManufacturerPartStatusCodeOther CDATA #IMPLIED referenceNotes CDATA #IMPLIED manufacturerPartType CDATA #IMPLIED description CDATA #IMPLIED owner CDATA #IMPLIED ownerContactUniqueIdentifier IDREF #IMPLIED isTopLevel (Yes | No ) #IMPLIED >
Attachments? , Contacts? , AsBuiltProduct*)>
Other ) #IMPLIED globalEngineeringChangeResponseCodeOther CDATA #IMPLIED comments CDATA #IMPLIED workflow CDATA #IMPLIED globalApproverTypeCode (Required |
Other ) #REQUIRED globalApproverTypeCodeOther CDATA #IMPLIED approverName CDATA #REQUIRED approverContactUniqueIdentifier IDREF #IMPLIED alternateApproverContactUniqueIdentifier IDREF #IMPLIED approvedDate CDATA #IMPLIED approverWorkflowStatus CDATA #IMPLIED alternateApproverName CDATA #IMPLIED >
The SupplierPart element includes essential attributes such as the required supplierPartIdentifier and supplierName, along with optional identifiers and status codes It also contains fields for reference notes, supplier part type, and owner information Additionally, the element specifies whether the part is a top-level item and may include a description and global return product instruction code.
The ProductInstance element requires an itemIdentifier and a materialIdentifier, while other attributes such as forecastProductIdentifier, purchaseOrder, and customerSerial are optional Additional attributes include purchaseOrderLineItem, authorizationLineItem, customerPart, and customerRevision, which may also be included The sequenceNumber, manufacturingPartStatus, customerVersion, globalLocationIdentifier, globalCountryCode, description, and proprietarySerialIdentifier are implied but not mandatory.