PipingNodeOwner¶

Overview¶

Abstract class

An object that can have PipingNodes.

Subtypes

Attributes (composition)

Name	Multiplicity	Type
Nodes	*	PipingNode

Implementation in Proteus Schema

Implementation is subclass-specific.

Example

As PipingNodeOwner is abstract, we consider CheckValve as an arbitrary concrete subclass.

Implementation in Proteus Schema

<PipingComponent
    ID="checkValve1"
    ComponentClass="CheckValve"
    ComponentClassURI="http://data.posccaesar.org/rdl/RDS292229" ...>
  ...
</PipingComponent>

Nodes¶

Attribute (composition)

The PipingNodes of the PipingNodeOwner.

Multiplicity: *

Type: PipingNode

Opposite multiplicity: 0..1

Implementation in Proteus Schema

The attribute is implemented using the XML hierarchy of the Proteus file. However, the <Node> elements for PipingNodes are not children of the XML element for the PipingNodeOwner itself; they are rather grouped in a single <ConnectionPoints> element that is placed in the XML element for the PipingNodeOwner.

Note that the first <Node> element in the <ConnectionPoints> cannot represent a PipingNode. In Proteus Schema, the first <Node> element corresponds to the PipingNodeOwner itself. It is not relevant for DEXPI, but it must be present according to the Proteus Schema specification. It must not have a Type attribute.

The further <Node> elements with Type="process" (cf. Proteus implementation of PipingNode) represent the Nodes of the PipingNodeOwner.

The following XML fragment shows the case of a PipingNodeOwner (more specifically, a PipingComponent) that has one PipingNode:

<PipingComponent ...>
  ...
  <ConnectionPoints NumPoints="4" ...>
    <!-- first Node is never relevant for DEXPI -->
    <Node ID="nonRelevantNode">...</Node>

    <!-- this is a PipingNode because Type is "process" -->
    <Node ID="aPipingNode" Type="process">...</Node>

    <!-- this is not a PipingNode because no Type is given -->
    <Node ID="someNode">...</Node>

    <!-- this is not a PipingNode because Type is not "process" -->
    <Node ID="someSignalNode" Type="signal">...</Node>
  </ConnectionPoints>
  ...
</PipingComponent>

In some cases, Proteus Schema uses the index of a <Node> element to refer to that <Node>. The index is the zero-based number of the <Node> in the <ConnectionPoints>. For example, in the XML fragment above, the index of the <Node> with ID="nonRelevantNode" is 0 and the index of the <Node> with ID="aPipingNode" is 1. These indices are an implementation detail of Proteus Schema, and they do not carry any additional semantics. The Nodes attribute of PipingNodeOwner is not ordered, i.e., a PipingNodeOwner in DEXPI does not have a first or second PipingNode.

Example

As the owner type PipingNodeOwner is abstract, we consider CheckValve as an arbitrary concrete subclass.

Implementation in Proteus Schema

<PipingComponent
    ID="checkValve1"
    ComponentClass="CheckValve"
    ComponentClassURI="http://data.posccaesar.org/rdl/RDS292229" ...>
  ...
  <ConnectionPoints ...>
    <Node ID="nonRelevantNode" />
    <Node ID="pipingNode1" Type="process">...</Node>
    ...
  </ConnectionPoints>
  ...
</PipingComponent>