Engineering Data Support

Appendix I. PES format

This appendix provides a description for the IBM Engineering Management for CIM products PES self-describing format.

Logical record format

Data which belongs logically together builds a unit which is called a logical record.

A logical record contains structure definitions and data fields. Structure definitions and data fields are concatenated to a string without space between them. Structures can be nested.

A typical record is shown below.

Figure I-1. Structure of logical record

|<----------- Logical Record (Header or Application data) ------------->|
*------------------------------------------------       ----------------*
|    |         |        |    |                   ......   |             |
*------------------------------------------------       ----------------*
|    |         |        |    |<-Field->|<-Fields ...... ->|             |
|    |<-Field->|<Field->|<-Structure--------------------->|<-Field(s)-->|
|<-Structure----------------------------------------------------------->|

It is good practice for you to have one structure in a physical record.

Self-describing format of fields and structures

The data fields are self-describing with a prefix and a following data area. A structure definition assembles a set of fields belonging logically together. Fields and structures are described by a prefix containing:

• Length (including the length of the prefix)
• Identifier
• Format definition
• Continuation indicator

Figure I-2. Structure layout

|<-Structure---------------------------------- . . . ------------------>|
*---------------------------------------------       -------------------*
|       |                |            |        . . .     |              |
*---------------------------------------------       -------------------*
|Struct.|<--Structure data-------------------- . . . ------------------>|
|prefix |<-----Field---->|<-Field---->|<------ . . . --->|<-Field(s)..->|
|       |
+++++++++
x        --- length of the length field (1 byte)
 x       --- length of (data + prefix)  (1 to 9 bytes)
  xxxx   ---- structure identifier      (4 bytes)
      x  ----- format definition (="S") (1 byte)
       x ------ continuation indicator  (1 byte)

A Structure defines a set of data fields with a structure identifier.

• Format definition is "S".
• Length is the length of the whole structure (including the prefix).
• Data area of a structure consists of fields with a layout as described above.

Structures can be nested. A Structure definition must not exceed a physical record. If the structure area is larger, a continuation must be defined in the next record with the same prefix identifier.

The layout of a field is similar:

Figure I-3. Field layout

 
                |<-Field--------------------------------->|
    ------------------------------------------------------------
                |       |                                 |
    ------------------------------------------------------------
                |Field  |<---------Data------------------>|
                |prefix |
                |       |
                +++++++++
                x        --- length of the length field (1 byte)
                 x       --- length of (data + prefix)  (1 to 9 bytes)
                  xxxx   ---- structure identifier      (4 bytes)
                      x  ----- format definition        (1 byte)
                       x ------ continuation indicator  (1 byte)

Length definition

The length is defined by the length of the length field (1 byte containing character 1 to 9) and the length of the structure or field including the prefix length (1 to 999999999). So the length definition determines that:

• Prefix length is 7 bytes plus the length of the length-field
• Next field (prefix) starts adding the length-definition to the current position.

A structure or field must not exceed the end of a physical record. If a logical field or structure doesn't fit into a record, it must be split (see "Continuation").

Identifier

Each structure and field has an identifier. The identifier string can be any non-BLANK character string with a maximum length of 4. Trailing blanks are allowed.

The communicating applications must agree to the set of identifiers used. Data with unknown identifiers should be ignored by the receiving applications to allow easy functional extension.

Format specification

A format byte can be used to define format or code page specification if necessary.

The following format definitions are reserved:

(" ") (BLANK)

Data is represented as characters.

("S")

Field prefix defines a structure, that means, that an area is defined with a structure name.

("D")

Date field in the format YYYYMMDD or YYMMDD (year month day in digits without delimiter; data length is accordingly 8 bytes or 6 bytes).

("T")

Time field in the format HHMMSSssss (hours minutes seconds and decimals of seconds without delimiter; data length is 6 bytes or more, that means decimals of seconds may be missing).

("N")

Numerics with decimal point in the format vnnn.dddevbb

         where  v = + or -; if missing + is assumed
              nnn = integers (0, 1, ...9)
              ddd = decimals (0, 1, ...9)
                E = char. "E" = exponent follows
                b = exponent on base 10
         Examples:
   123 =  +0123 =  1.23E2 =  123.0E0
 -.025 = -0.025 = -2.5E-2 = -.25E-01

Continuation

A structure or field must not exceed the record length. If a data field or a structure must be split, a continuation character "C" indicates this. The continuation must be found in the next following record. Continuation of fields must only be used for character string representation.

General rules

When implementing this interface for a specific environment, follow these rules:

1. The first structure of a data group must be the header.

2. The last structure must be the trailer.

3. The data structures and fields are concatenated to a data string with no space between.

4. Each field is a member of a structure (the structure ID can be regarded as record type).

5. Each physical record begins with a structure definition.

6. If formatted in fixed length record format, unused space (after the last valid data field) must be filled with BLANK (x'40') or NULL (x'00').

7. Multiple occurrences of same identifiers are allowed. Generally, the sequence of the data fields is free. However if dependencies exist, the sequence of fields determine the relationship. For instance, a list of item numbers with its engineering change numbers are represented by the sequence ITNO ECNO ITNO ECNO ITNO ECNO .... to indicate which ECNO belongs to which ITNO. A better representation for relationships is the use of structure definitions.

8. Split structures and fields must be continued in the next physical record.

9. Nested structures cannot extend the end of a higher-level structure.

Header data

The header data is defined in a self-describing format.

The first structure of each request and feedback data group is always a header. Only one header structure must be in a data group.

A structure identifier of "HEAD" precedes the header data definitions. The header structure includes all control data necessary for data transfer and feedback handling.

The following definitions apply to the header structure:

Table I-1. HEAD Structure

Structure ID	Field ID	Content
HEAD	RTYP	Request type: - Determines the processing (transaction). - The currently designed request types are beginning with "HR" for request data groups. Feedback data groups have the request type of the request data group, but "HR" is changed to "HF".
	SEND	Senders ID: - Required. - Nickname or user ID/node ID.
	TARG	Target ID (receiver): - Required. - Nickname or user ID/node ID.		RQNO	Request number: - Required. - Unique number for sender to identify request. - May be a time stamp.
	RFNO	Reference request number: - In feedback records, the referred request number. - Not applicable for request records.

Application data

One application communicates with another either by sending data, or asking for data to be returned, or both. Any type of data can be sent. The data can be used to control processing of programs or to exchange user data.

Each application, which communicates using this interface, can define its special parameter data and user data to be transferred with his transactions.

Unformatted data strings (for example, geometry data, NC-data or text files) are treated as fields. If necessary, the data string is split with each physical record, or at the maximum length of 65535 bytes.

Trailer

To indicate the end of the data, a trailer must follow. The trailer is a structure prefix with the structure identification "TAIL". Data fields are not expected in the TAIL structure but can be included for control purposes.

Table I-2. CADD Structure

Structure ID	Field ID	Content
CADD	CSYS	Computer Aided Design system e.g. 'CADAM**' or 'CATIA*' or 'CADAM21'
	CGRP	Computer Aided Design group
	CUSR	Computer Aided Design user (subgroup)
	CFIL	Drawing-file ID (not for CADAM)
	CMOD	Model-ID (drawing)
	SIZE	Drawing size
	DENG	Engineer responsible for drawing
	DATE	Drawing creation date (format = D)

ITEM: item data

The item is a simple part or an assembly. The item data describe parts or assemblies.

The following data fields are predefined to describe items and can be used in the ITEM structure:

Table I-3. ITEM Structure

Structure ID	Field ID	Content
ITEM	ITNO	Item number
	DSCS	Description short
	DSCL	Description long
	UOMS	Unit of measure
	ITYP	Item type
	RTNO	Routing number
	RTTY	Routing type
	COST	Unit cost (format = N)
	SURF	Surface quality
	MTRL	Material
	UDIM	Unit of dimensions
	LNGT	Length (format = N)
	HGHT	Height (format = N)
	BRDT	Breadth (format = N)
	DIAM	Diameter (format = N)
	UWGT	Unit of weight
	WGHT	Weight (format = N)
	STDD	Standard (e.g.ISO, DIN) number

ECHD: engineering change data

The Engineering Change Data, which can be transferred between a computer aided design system and a planning system, is defined in this structure.

The following fields are predefined for engineering changes and can be used in the "ECHD" structure.

Table I-4. ECHD Structure

Structure ID	Field ID	Content
ECHD	ECNO	Engineering change number
	EDAT	EC effectivity date (format = D)
	EETC	EC effectivity type code
	EENG	EC engineer
	EDSC	EC description
	ESNO	EC serial number (from)
	ESNT	EC serial number to
	ESCD	EC status code
	ERCD	EC reason code
	EEDT	Date EC entered (format = D)
	EPRV	Previous EC

COMP: component data

The Component data defines the components of an assembly. Although, for a BOM structure, only the minimum fields are required. Often, additional data is transferred to have usable bill of materials.

The following fields are predefined for component data and can be used in the "COMP" structure.

Table I-5. COMP Structure

Structure ID	Field ID	Content
COMP	ITNO	Component (item) number
	POSI	Position number in BOM
	DSCS	Description short
	QNTY	Quantity (format = N)
	UOMS	Unit of measure for quantity
	ESTT	Engineering status
	COPT	Category option
	VOPT	Value option
	ACOD	Action code
	PCOD	Phantom code
	EPCO	Engineering Planning Code
	MPCO	Manufacturing Planning Code
	CTYP	Component type
	CEFD	Component effectivity date (from) (format = D)
	CEFT	Component effectivity date to (format = D)
	BSCO	Engineering BOM status code
	CTXT	Comment to BOM position
	CSUF	Component suffix
	COFA	Offset adjustment
	CPON	Parent operation number

The "CREF" structure is nested in the "COMP" structure and can occur multiple times. It defines substitute and optional parts for a component.

TEXT: text data

This record type has an undefined layout. Any text or other data can be transferred with this record. You can define the layout of text records for special purposes.

No required fields are defined in the data area of the "TEXT" record.

PMSG: message feedback

If processing was not completely successful, return code and message is returned to the requestor with this record.

Table I-6. PMSG Structure

Structure ID	Field ID	Content
PMSG	RETC	Return code
	MSGN	Message number
	MESS	Message