Extensions and Modifications of Proteus Schema for IIMM Instrumentation Model

0.1 2015-10-27 Manfred Theißen, AixCAPE initial version

This document describes a proposal for extending Proteus schema in order to support the new IIMM instrumentation model.

New Element:  top-level element in  in the are assigned via elements (cf. InstrumentLoop in Proteus 3.6.0)

Example:

New Element:  top-level element in , even if part of a

 are optionally assigned to a via an elements (cf. InstrumentLoop in Proteus 3.6.0; redundancy accepted for now for consistency with Proteus 3.6.0)

 ProcessControlFunction:

o subclass of ProcessControlRequirement

o no schema class required (RDL reference sufficient)

Example:

New Elements: ,  children of < ProcessControlRequirement>

 / are assigned via (Multiplicity - is 1..*. Hence, assigning as XML children will not work in general.)

Existing Element:  As many objects in the conceptual model are not necessarily represented in a PID graphics, there is a mismatch between the associations of as indicated in the conceptual model and the shapes that are connected by the drawing of a .

 Use (incl. ) as described in Proteus 3.6.0

 In addition: give conceptual associations.  Existing association types are not well documented, but probably none fits.Thus added:

o “has logical start”/”is logical start of”

o “has logical end”/”is logical end of”

 Direction of should match information flow where applicable.

Example:

New Elements: ,  Top-level elements in

 Assignment to / via with type “fulfills”/”is fulfilled by”

 Assignment of parts via with type “is an assembly including” (optionally with RDF reference, e.g., to identify the “DetectingElement” or the “Transmitter” independent from the type of the referenced object)

Graphics  In principle, graphical representations for all objects above are optional; thus, PlantItem is an adequate XSD type for all of them

 Details of graphics depend on the underlying standard; they should be covered by the existing schema elements