XML Model Details

To successfully export data to the 12.0 SP4 version of PDMS or earlier, the XML model details must conform to certain rules.

• XML File Document Structure

The document structure is defined in the XML schema for the P&ID profile. An output file that conforms to this document must validate against the profile schema.

The first line of the file must be an XML declaration, for example:

The document is to be encoded using UTF-8.

The root node of an XML file is a PlantModel element.

XML elements are not defined within an XML namespace and so are not namespace qualified.

The following class model provides an overview of the significant structural elements contained within an AVEVA P&ID XML profile file. The bi-directional arrows indicate and parent/child element relationship in the XML file.

The elements and their attributes are defined in the Element Definitions section.

Each structural element may contain geometric and text elements to represent the drawing contents.

XML Topology

A PipingNetworkSegment, as its upstream reference (PipingNetworkSegment/Connection/@FromID), will reference a Nozzle, splitting component (such as a Tee, Wye or Cross), Reducer or SpecificationBreak that it doesn't contain or it will reference a PipeConnector that it contains.

A PipingNetworkSegment, as its downstream reference (PipingNetworkSegment/Connection/@ToID), will reference a Nozzle, merging component (such as a Tee, Wye or Cross) or SpecificationBreak that it doesn't contain or it will reference a splitting component (such as a Tee, Wye or Cross), Reducer or PipeConnector that it contains. Nb All PipingNetworkSegment elements are split where there is splitting component ( such as a Tee, Wye or Cross) or a Reducer.

Contained components, with the exception of PipeConnectors require a ToNode attribute which references the downstream ConnectionPoint of the component (for example, the main flow out of the segment).

Components contained by other segments must be referenced using a ToNode or FromNode attribute as appropriate.

References to Nozzle, PipeConnector and SpecificationBreak elements do not require ToNode/FromNode attributes.

Geometries (Axis and Reference)

All geometries in an XMpLant file are accompanied by Axis and Reference elements. These define rotations around 3 dimensional axis that define how to map the coordinates defined for the item into the target environment. For most 2D drawing work the following values give the expected behaviour (for example, the coordinates are defined in the 2D drawing plane).

<Axis X="0" Y="0" Z="1"/>

<Reference X="1" Y="0" Z="0"/>

Some curve primitives such as ellipses in XMpLant require more complex use of Axis and Reference in order to define the 2D forms.

The <Axis> value defines a unit vector in 3D space about which an object should rotate. For 2D diagrams nearly all geometries will define this element as <Axis X="0" Y="0" Z="1"/> which denotes a vector aligned with the Z-axis.

The <Reference> element defines what is effectively the rotation about the <Axis> element. When you see the value written as <Reference X="1" Y="0" Z="0"/> it indicates that the X-Axis with which the object's points are defined use the same X-Axis on the output surface/window with which to orientate - in other words no rotation is required when you have the following paired elements;

<Axis X="0" Y="0" Z="1"/>

<Reference X="1" Y="0" Z="0"/>

Character Encoding

XML is encoded using UTF-8. This means that most characters used in western languages are encoded using a single byte representation, more complex characters are encoded using either a 2 byte encoding or a substitution mechanism. Where the export capabilities are limited to a single byte representation or software is developed with limited knowledge of UTF-8 it is common practice to output the 2 byte characters using a numerical substitution syntax of &#nnn; where nnn denotes the character code.

P&ID Manager is very limited in the way that characters are supported because the base storage has fixed length text types (120 characters) and limited character support. If two byte characters are provided to P&ID Manager then they will be substituted numerically when stored so that the database character constraints can be met. This substitution compromises the amount of text stored as a single character will be converted to ~5 characters to complete the substitution. When exporting to XML bear in mind that the string data contents loaded into P&ID Manager will be constrained to 120 characters in length after two byte characters have been substituted numerically and XML substitutions have been reversed (such as ‘?’ -> ‘&#FEA6;’, ‘&amp;’ ->’&’, ‘&lt;’ -> ‘<’ etc).

Tag Referencing

Tag attributes may be used to reference elements instead of referencing by the ID attribute. The XML profile prefers the use of ID referencing as it gives a consistent referencing mechanism that can be used regardless of the presence of a Tag attribute.

If Tags are used then there is a special case for referencing Nozzle elements. In this instance the Tag is only unique within the scope of the containing Equipment element so the Equipment Tag must also be included in the reference. The reference must have the form <EquipmentTag>-<NozzleTag> and can only be used where the <NozzleTag> component doesn’t contain a ‘-‘ character.

For Example:

Where:

Equipment/@Tag = ‘VP-1234-DNJ09’

Equipment/Nozzle/@Tag = ‘N1’

The reference would be:

VP-1234-DNJ09-N1

PersistentId Referencing

As long as the context attribute used to scope PersistentID elements is at least equal in scope to the file scope then PersistentId attributes may be used for cross referencing elements. The PersistentID/@Identifier value is supported I any ItemId attribute.